Concurrenthashmap & copyonwritearraylist &

Concurrenthashmap vs. hashmap/synchronizedmap/hashtable

• When to use concurrenthashmap () to read and write concurrency. It is better than hashmap in terms of its concurrency. The read is not locked. When writing, the lock granularity is reduced to segment rather than the whole table, which means "concurrent writing" can be performed to a certain extent ". It seems that with concurrent, hashmap won't be favored ..
• Concurrenthashmap, do not use. Size () easily because it locks the entire table;
• Concurrenthashmap, do not use. Remove () easily, because it involves copying all elements before the entry in hashtable (why? Because the entry except the value field is a variable, the other are final, so that the index does not need to be synchronized, and the performance is faster ).

Http://xuganggogo.iteye.com/blog/321630

Http://www.ibm.com/developerworks/cn/java/j-jtp07233/

Http://www.ibm.com/developerworks/cn/java/java-lo-concurrenthashmap/index.html? CA = Drs-

Copyonwritearraylist vs. arraylist

• The copyonwritearraylist is highly efficient because it has many reads and few writes. Why? If it is a normal arraylist, You need to lock the entire list and write it one by one during write and multi-thread concurrent access. How efficient is this?
• Copyonwritearraylist to implement read/write splitting. No lock during reading is not blocked (iterator points to an original read since its birth, because the write is written on the copy, there will be no read problems ), you can write data on the copy when writing data. After writing, the pointer atom points to you and takes effect according to you.
• Two problems:

(1) This so-called "copy" involves arrays. copyof () the entire array replication problem, and the use of reentrantlock (re-entry lock) synchronization, is bound to affect efficiency, so it is not suitable for copyonwritearraylist when writing too much.

(2) How to Prevent concurrent writing? Everyone is taking a copy and writing it. How is this good? You must not be able! Copyonwritearray locks a person before preparing a copy until he finishes changing the lock to release the copy. Other people can pull the copy. In other words, the Set (), add (), and remove () operations are all synchronized (), and the copy copyin () operation is also synchronized.

Http://www.cnblogs.com/sunwei2012/archive/2010/10/08/1845656.html

Http://blog.csdn.net/tsyj810883979/article/details/6891540

• Give a case

 

String[] strs = {"111","222","333"};

List<String> list1 = new CopyOnWriteArrayList<String>(Arrays.asList(strs));

List<String> list2 = new ArrayList<String>();

Iterator <string> itor1 = list1.iterator (); // pre-write iterator

Iterator <string> itor2 = list2.iterator (); // pre-write iterator

list1.add("New");

list2.add("New");

try {

Printall (itor1); // The iteration is correct. Enter 111,222,333

} catch (ConcurrentModificationException e) {

  System.err.println("Shouldn't get here");

}

try {

Printall (itor2); // an exception is thrown at itor. Next () during iteration.

} catch (ConcurrentModificationException e) {

  System.err.println("Will get here.");

}

private static void printAll(Iterator<String> itor) {

while (itor.hasNext()) {

  System.out.println(itor.next());

}

Symptom explanation:When the iterator is created before writing, itor1 sees 111,222,333, while itor2 sees null. After the list1 (copyonwrite) is modified, the itor1 read process can still be read 111,222,333, list2 (arraylist) throws an exception because it finds that expectedcount and modecount do not match. Reading is also exquisite. itor1 can always read the value (although not the latest), and itor2 does not always read the value (but this can also prevent the value from being modified ), in short, each has its own merits.