1. In many situations, the JDK concurrent collection framework was your fist choice except:

• IBM machine
• Window Azue
• Other JDK vendor

2. Library wasn't common or portable when the high scalability or performance is required. You need better understand your mahcine or system.

3. Entry, key data structure defined in many collections, node allocation was already in guarded. So make sure not put the "new" operation inside the lock scope.

4. Keep using the latest version of JDK concurrent library as you can. They always keep tracing the best result offer for you.

5. Little trick can bring huge return, for instance:

    Do you know why synchronized hash map still better than hash table in some conditions? As HashMap use the "==" first then try "Equals", so that's reason why concurrent library provide ConcurrentHashMap than ConcurrentHashTable.

6. Please evaluate your requirement, read only, write only, read most write rarely, read and write almost equals. Then seek better solutions for you. Not blendly trust other person testing results. (Of course, you should suspect my results either )

7. JDK leverage CAS resolving the consistency of memory and it was the key break through for our concurrent programming toolkits. But it has limitations, so STM (Software Transaction Memory), HTM  (Hardware Transaction Memeory) will help you resolve the consistency in high concurrent env.

8. Do you consider the memory fragment after you leverage the collections especially you have large chunk of data put/get/remove and each item consume large memory size either? If true, please isolate key word and information storage. One interesting implemenation for your reference Clojure's persistence vector or map.

Any thoughts from you? Hope we can provide the long list for our future reference! That's my dream.