Safe is first,performance is second.
1、性能思考
使用多线程总会引入一些性能开销：与协调线程相关的开销（加锁、信号、内存同步），增加上下文切换，线程的创建和消亡，以及调度的开销。
可伸缩性：指的是当增加计算资源的时候（比如增加额外CPU数量、内存、存储器、I/O带宽），吞吐量和生产量能够相应地得以改进。
从性能的多个角度来看：“有多少”方面——可伸缩性，吞吐量和生产量，在Server应用程序中往往比“有多快”受到更多的关注。
避免不成熟的优化。首先使程序正确；如果它运行得还不够快，再加快。
在决定某个方案比其他方案“更快”之前，先问自己一些问题：
1）你所谓的更“快”指的什么？
2）在什么样的条件下你的方案能够真正运行的更快？在轻负载还是在重负载下？大数据集还是小数据集？是否支持你的测量标准的答案？
3）这些条件在你的环境中发生的频率？是否支持你的测量标准的答案？
4）这些代码在其他环境的不同条件下被用到的可能性？
5）你用什么隐含的代价，比如增加的开发风险或维护性，换取了性能的提高？这个权衡的决定是否正确？
对性能的追求很可能是并发bug唯一最大的来源。测评，不要臆测。
2、Amdahl定律
Amdahl定律描述了在一个系统中，基于可并行化和串行化的组件各自所占的比重，程序通过获得额外的计算资源，理论上能够加速多少。
如果F是必须串行化执行的比重，那么Amdahl定律告诉我们，在一个N处理器的机器中，我们最多可以加速：Speedup <= 1/（F+（1-F）/N）
所有并发程序都有一些串行源；如果你认为没有，那么去仔细检查吧。
3、线程引入的开销及减少锁的竞争
不要过分担心非竞争的同步带来的开销。基础的机制已经足够快了，在这个基础上，JVM能够进行额外的优化，大大减少或消除了开销。关注那些真正发生了锁竞争的区域中性能的优化。
并发程序中，对可伸缩性首要的威胁是独占的资源锁。
有3种方式来减少锁的竞争：
- 减少持有锁的时间（缩小锁的范围）；
- 减少请求锁的频率（分拆锁和分离锁）；
- 或者用协调机制取代独占锁，从而允许更强的并发性。
每个变化操作都要访问它（比如计算HashMap的计算器），称为热点域。
不均匀的CPU利用率表明，大多数计算都由很小的线程集完成，你的应用程序将不能够利用额外的处理器资源。
4、比较Map的性能
ConcurrentHashMap要比同步的HashMap的性能好。
ConcurrentHashMap和ConcurrentSkipListMap的数据显示，它们能很好地应对数量很大的线程；吞吐量随着线程数量的增加而增长。
5、减少上下文切换引起的开销
把I/O操作移到了另一个线程，使用户看不到这个开销；同样取消了输出流竞争，因此较少了竞争源。