常见的并发陷阱
volatile
volatile只能强调数据的可见性，并不能保证原子操作和线程安全，因此volatile不是万能的。参考指令重排序
volatile最常见于下面两种场景。
a. 循环检测机制
volatile
boolean done =
false;
while( ! done ){
dosomething();
}
b. 单例模型 （http://www.blogjava.net/xylz/archive/2009/12/18/306622.html）
public class DoubleLockSingleton {
private static volatile DoubleLockSingleton instance = null;
private DoubleLockSingleton() {
}
public static DoubleLockSingleton getInstance() {
if (instance == null) {
synchronized (DoubleLockSingleton.class) {
if (instance == null) {
instance = new DoubleLockSingleton();
}
}
}
return instance;
}
}
synchronized/Lock
看起来Lock有更好的性能以及更灵活的控制，是否完全可以替换synchronized？
在锁的一些其它问题中说过，synchronized的性能随着JDK版本的升级会越来越高，而Lock优化的空间受限于CPU的性能，很有限。另外JDK内部的工具（线程转储）对synchronized是有一些支持的（方便发现死锁等），而对Lock是没有任何支持的。
也就说简单的逻辑使用synchronized完全没有问题，随着机器的性能的提高，这点开销是可以忽略的。而且从代码结构上讲是更简单的。简单就是美。
对于复杂的逻辑，如果涉及到读写锁、条件变量、更高的吞吐量以及更灵活、动态的用法，那么就可以考虑使用Lock。当然这里尤其需要注意Lock的正确用法。
Lock lock =
lock.lock();
try{
//
do something
} finally{
lock.unlock();
}
一定要将Lock的释放放入finally块中，否则一旦发生异常或者逻辑跳转，很有可能会导致锁没有释放，从而发生死锁。而且这种死锁是难以排查的。
如果需要synchronized无法做到的尝试锁机制，或者说担心发生死锁无法自恢复，那么使用tryLock()是一个比较明智的选择的。
Lock lock =
if(lock.tryLock()){
try{
// do something
} finally{
lock.unlock();
}
}
甚至可以使用获取锁一段时间内超时的机制Lock.tryLock(long,TimeUnit)。 锁的使用可以参考前面文章的描述和建议。
锁的边界
一个流行的错误是这样的。
new ConcurrentHashMap<String,String>();
if(!map.containsKey(key)){
map.put(key,value);
}
看起来很合理的，对于一个线程安全的Map实现，要存取一个不重复的结果，先检测是否存在然后加入。 其实我们知道两个原子操作和在一起的指令序列不代表就是线程安全的。 割裂的多个原子操作放在一起在多线程的情况下就有可能发生错误。
实际上ConcurrentMap提供了putIfAbsent(K, V)的“原子操作”机制，这等价于下面的逻辑：
if(map.containsKey(key)){
return map.get(key);
} else{
return map.put(k,v);
}
除了putIfAbsent还有replace(K, V)以及replace(K, V, V)两种机制来完成组合的操作。
提到Map，这里有一篇谈HashMap读写并发的问题。
构造函数启动线程
下面的实例是在构造函数中启动一个线程。
public class Runner{
int x,y;
Thread thread;
public Runner(){
this.x=1;
this.y=2;
this.thread= new MyThread();
this.thread.start();
}
}
这里可能存在的陷阱是如果此类被继承，那么启动的线程可能无法正确读取子类的初始化操作。
因此一个简单的原则是，禁止在构造函数中启动线程，可以考虑但是提供一个方法来启动线程。如果非要这么做，最好将类设置为final，禁止继承。
丢失通知的问题
这篇文章里面提到过notify丢失通知的问题。
对于wait/notify/notifyAll以及await/singal/singalAll，如果不确定到底是否能够正确的收到消息，担心丢失通知，简单一点就是总是通知所有。
如果担心只收到一次消息，使用循环一直监听是不错的选择。
非常主用性能的系统，可能就需要区分到底是通知单个还是通知所有的挂起者。
线程数
并不是线程数越多越好，在下一篇文章里面会具体了解下性能和可伸缩性。 简单的说，线程数多少没有一个固定的结论，受限于CPU的内核数，IO的性能以及依赖的服务等等。因此选择一个合适的线程数有助于提高吞吐量。
对于CPU密集型应用，线程数和CPU的内核数一致有助于提高吞吐量，所有CPU都很繁忙，效率就很高。 对于IO密集型应用，线程数受限于IO的性能，某些时候单线程可能比多线程效率更高。但通常情况下适当提高线程数，有利于提高网络IO的效率，因为我们总是认为网络IO的效率比较低。
对于线程池而言，选择合适的线程数以及任务队列是提高线程池效率的手段。
public ThreadPoolExecutor(
int corePoolSize,
int maximumPoolSize,
long keepAliveTime,
TimeUnit unit,
BlockingQueue<Runnable> workQueue,
ThreadFactory threadFactory,
RejectedExecutionHandler handler)
对于线程池来说，如果任务总是有积压，那么可以适当提高corePoolSize大小；如果机器负载较低，那么可以适当提高maximumPoolSize的大小；任务队列不长的情况下减小keepAliveTime的时间有助于降低负载；另外任务队列的长度以及任务队列的拒绝策略也会对任务的处理有一些影响.