HashMap不是多线程安全的,这个貌似大家都知道,但是这是不是意味着,只要在多线程环境下使用到HashMap,那就得套上syncronized呢?
引用
Hash table based implementation of the Map interface. This implementation provides all of the optional map operations, and permits null values and the null key. (The HashMap class is roughly equivalent to Hashtable, except that it is unsynchronized and permits nulls.) This class makes no guarantees as to the order of the map; in particular, it does not guarantee that the order will remain constant over time.
HashMap是基于Hash Table的一种Map实现,允许null values和null key(它跟HashTable的区别在于它是非同步的,而且允许null key和null values),HashMap不保证Map的顺序,甚至不能保证Map的顺序在运行过程中保持不变。
引用
Note that this implementation is not synchronized. If multiple threads access this map concurrently, and at least one of the threads modifies the map structurally, it must be synchronized externally. (A structural modification is any operation that adds or deletes one or more mappings; merely changing the value associated with a key that an instance already contains is not a structural modification.) This is typically accomplished by synchronizing on some object that naturally encapsulates the map. If no such object exists, the map should be "wrapped" using the Collections.synchronizedMap method. This is best done at creation time, to prevent accidental unsynchronized access to the map:
Map m = Collections.synchronizedMap(new HashMap(...));
这种实现不是同步的,如果多个线程同时访问这个Map,而且至少一个线程对Map进行结构性的修改(增加,删除操作,update不算),那么它必须在外部进行同步,通常这种同步是通过包含这个Map的外部对象来实现的,如果该外部对象不存在,那么这个Map需要通过Collections.synchronizedMap来保证同步(最好在创建的时候)。
引用
The iterators returned by all of this class's "collection view methods" are fail-fast: if the map is structurally modified at any time after the iterator is created, in any way except through the iterator's own remove or add methods, the iterator will throw a ConcurrentModificationException. Thus, in the face of concurrent modification, the iterator fails quickly and cleanly, rather than risking arbitrary, non-deterministic behavior at an undetermined time in the future.
Note that the fail-fast behavior of an iterator cannot be guaranteed as it is, generally speaking, impossible to make any hard guarantees in the presence of unsynchronized concurrent modification. Fail-fast iterators throw ConcurrentModificationException on a best-effort basis. Therefore, it would be wrong to write a program that depended on this exception for its correctness: the fail-fast behavior of iterators should be used only to detect bugs.
话说,没看懂~~
关于fail-fast,中文意思是快速失败,没搜到官方的解释(搜索技术不好?),找到这个问答
http://www.jguru.com/faq/view.jsp?EID=221988
引用
An iterator is considered fail-fast if it throws a ConcurrentModificationException under either of the following two conditions:
1. In multithreaded processing: if one thread is trying to modify a Collection while another thread is iterating over it.
2. In single-threaded or in multithreaded processing: if after the creation of the Iterator, the container is modified at any time by any method other than the Iterator's own remove or add methods.
来自ibm developerworks上对java.util.concurrent包的说明片段:
java.util 包中的集合类都返回 fail-fast 迭代器,这意味着它们假设线程在集合内容中进行迭代时,集合不会更改它的内容。如果 fail-fast 迭代器检测到在迭代过程中进行了更改操作,那么它会抛出 ConcurrentModificationException ,这是不可控异常。
在迭代过程中不更改集合的要求通常会对许多并发应用程序造成不便。相反,比较好的是它允许并发修改并确保迭代器只要进行合理操作,就可以提供集合的一致视图,如 java.util.concurrent 集合类中的迭代器所做的那样。
java.util.concurrent 集合返回的迭代器称为弱一致的(weakly consistent)迭代器。对于这些类,如果元素自从迭代开始已经删除,且尚未由 next() 方法返回,那么它将不返回到调用者。如果元素自迭代开始已经添加,那么它可能返回调用者,也可能不返回。在一次迭代中,无论如何更改底层集合,元素不会被返回两次。
算了,如果多线程用到HashMap,如果不能保证是只读的,还是给它套个syncronized好了~~
丫的我还真没钻研精神~~