java.util.concurrent介绍(转载)
?
线程
ConcurrentHashMap
Hashtable
1
1.0
1.51
2
1.44
17.09
4
1.83
29.9
8
4.06
54.06
16
7.5
119.44
32
15.32
237.2
?
Lock 与 synchronized 与原子
??? 下列基准说明了使用 java.util.concurrent 可能改进可伸缩性的例子。该基准将模拟旋转骰子，使用线性同余随机数生成器。有三个可用的随机数生成器的实现：一个使用同步来管理生成器的状态（单一变量），一个使用 ReentrantLock，另一个则使用 AtomicLong。下图显示了在 8-way Ultrasparc3 系统上，逐渐增加线程数量时这三个版本的相对吞吐量。（该图对原子变量方法的可伸缩性描述比较保守。）
图 1. 使用同步、Lock 和 AtomicLong 的相对吞吐量
? 
公平与不公平
??? java.util.concurrent 中许多类中的另外一个定制元素是"公平"的问题。公平锁定或公平信号是指在其中根据先进先出（FIFO）的原则给与线程锁定或信号。ReentrantLock、Semaphore 和 ReentrantReadWriteLock 的构造函数都可以使用变量确定锁定是否公平，或者是否允许闯入（线程获得锁定，即使它们等待的时间不是最长）。
??? 虽然闯入锁定的想法可能有些可笑，但实际上不公平、闯入的锁定非常普遍，且通常很受欢迎。使用同步访问的内置锁定不是公平锁定（且没有办法使它们公平）。相反，它们提供较弱的生病保证，要求所有线程最终都将获得锁定。
??? 大多数应用程序选择（且应该选择）闯入锁定而不是公平锁定的原因是性能。在大多数情况下，完全的公平不是程序正确性的要求，真正公平的成本相当高。下表向前面的面板中的表中添加了第四个数据集，并由一个公平锁定管理对 PRNG 状态的访问。注意闯入锁定与公平锁定之间吞吐量的巨大差别。
图 2. 使用同步、Lock、公平锁定和 AtomicLong 的相对吞吐量
? 
结束语
??? java.util.concurrent 包中包含大量有用的构建快，可以用它们来改进并发类的性能、可伸缩性、线程安全和可维护性。通过这些构建快，应该可以不再需要在您的代码中大量使用同步、wait/notify 和 Thread.start()，而用更高级别、标准化的、高性能并发实用程序来替换它们。
Exchanger
CyclicBarrier
Synchronizer
?
原帖地址：http://www.cnblogs.com/sarafill/archive/2011/05/18/2049461.html
