Concurrent Read/Write Map

hehe，Doug Lea大佬早就有现成的包了，1。5就是把他的包弄进去的。
1。4以及以前的可以用Doug Lea的那个包。

http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html

A version of Hashtable that supports mostly-concurrent reading, but exclusive writing.

仔细看了api，好像跟buaawhl介绍的不一样啊。ConcurrentHashMap 支持并发的读写，从外部看无lock啊。从实现上来看，把table分成多个段，并发访问多个不同段，不会导致锁定。

When locking presents liveness or performance problems for a given class or program, usually the best solution is to refactor the design to use one or more of the other approaches presented in this chapter. However, there are cases where the basic logic of a synchronization-based design can be maintained even when some of the synchronized method qualifiers or blocks are removed, although sometimes at the expense of weakened semantic guarantees.

Synchronizing a field accessor method sometimes (but by no means always) adds noticeable overhead to programs. Two considerations enter into any decision about whether synchronization of an accessor method can be removed:

Legality. The value of the underlying field never assumes an illegal value; that is, you can ensure that the field never, even momentarily, breaks invariants. (This by definition excludes fields of type long and double.)

Staleness. Clients do not necessarily require the most recently updated value of a field, but can live with possibly stale values (see § 2.2.7).

If a field is not always legal, then the choices are:

Synchronize the accessor (as well as all update methods).

Ensure somehow that clients realize when they have obtained an illegal value and take evasive action (for example via double-checks — see § 2.4.1.2).

Omit the accessor method. This applies surprisingly often. Ask yourself why any client would want to know the value of a field and what they could do with this value. Because object attributes can change asynchronously in concurrent programs, a value obtained by a client in one line of code may have changed before the next line of code is executed. Thus, accessor methods are not frequently useful in concurrent programs. Moreover, because they are not frequently useful, synchronization is unlikely to be a performance concern even if you do not remove the accessor methods in such cases.

If a field is always legal but staleness is not acceptable, then you have the additional choice:

Remove synchronization from the accessor, and qualify the instance variable as volatile. However, this works as expected only for scalar types, not references to arrays or Objects that help maintain object representations: accessing a volatile reference does not automatically ensure visibility of the fields or elements accessible from that reference. (In the case of Object references, you can if necessary further ensure that the accessed fields are themselves volatile.) The main disadvantage of this approach is that volatile declarations impede compiler optimizations of methods using these fields, and so can lead to a net performance loss.

If a field is always legal and staleness is acceptable, then you also have the choices:

Remove synchronization from the accessor without any further alteration.

If you like to live dangerously, just make the field public.

As an example, consider the size() method of the ExpandableArray class (§ 2.2.2), that returns the value of the size field. Inspection of all methods reveals that the value of the size field is always legal — it never assumes a value outside the range 0..data.length. (This would not be true if, for example, size were temporarily set to -1 as a resize indicator flag inside the add method.) Assuming that this constraint is documented as an internal requirement for all subclasses and future modifications, then synchronization can be removed from the accessor.

The decision about staleness and need for volatile is a matter of judgment about possible usage contexts that here interacts with (among other issues) choice of traversal strategies. If clients mainly traverse elements using indexed loops:


for (int i = 0; i < v.size(); ++i) // questionable
System.out.println(v.get(i));

then obtaining stale values of size is not likely to be acceptable. For example, a client might obtain the value zero even when there are many elements in the array, thus skipping the loop entirely. Note that if the loop ran at all, the synchronization performed in the first invocation of method get would force a fresher value of size to be returned on the second and subsequent calls to size(). (Also recall from § 2.2.3 that clients must in any case be prepared for the size to change between the index check and the element access, so this traversal style is problematic at best anyway.)

However, if either aggregates or iterators are used, each performing internal synchronization, then you could make an argument for leaving the size() method unsynchronized and the size field non-volatile, and advertising the method as only a heuristic estimate of the current number of elements. Still, this is unlikely to be acceptable to clients of a general-purpose class such as ExpandableArray. But similar reasoning may be invoked when it is acceptable for clients to obtain values that are guaranteed to be only as recent as the last synchronization points of reading and writing threads.

Note however that volatile has been incompletely implemented in most JVMs. Using volatile may not help to achieve the results you desire (yes this is a JVM bug, but its been low priority until recently).

does not automatically ensure visibility of the fields or elements accessible from that reference

既然每次写的时候都需要手工同步一下读写的值,read的变量又是volatile,单独有一个write变量也需要占用空间,而且还需要花费力气让两者同步,直接定义一个变量是volatile就行了吧.这里没看出分开的必要.

http://www.javaperformancetuning.com/news/qotm030.shtml

不过，buaawhl可能写得比较匆忙，维护了两个hashmap,空间上需要两倍，这里可以改进一下，只需要维护一个hashmap既可。

public synchronized void clear() {
mapToRead=getNewMap();
}