目录：
3.Lock、ReentrantLock和Synchronized
1.避免活跃度危险
安全性和活跃度通常相互牵制。使用锁来保证线程安全，但是滥用锁可能引起锁顺序死锁；使用线程池和信号量来约束资源的使用，但是却可能使活动形成资源死锁
1.1 死锁
当一个线程永远占有一个锁，而其他线程尝试去获得这个锁，那么它们将永远被阻塞。当线程A占有锁L时，想要获得锁M，但是同时，线程B持有锁M，并尝试获得锁L，两个线程将永远等待下去。这种情况是死锁最简单的形式（致命的拥抱，deadly embrace）。发生在多个线程因环路的锁依赖关系而永远等待的情况下。与很多其他的并发危险相同，死锁很少能被立即发现。一个类如果有发生死锁的潜在可能并不意味着死锁每次都将发生，它只发生在该发生的时候。当死锁出现的时候，往往是遇到了最不幸的时候----在高负载之下。
DB系统的避免死锁设计：一个事务（transaction）可能需要获取锁，并可能一直持有这些锁，直到所有事务都提交。DB的处理：当DB监测到一个事务集发生了死锁（通过在表示==正在等待（is-waiting-for）==关系的有向图上搜索循环），它会选择一个牺牲者，使它退出事务。这个牺牲者释放的资源，使得其他事务能够继续进行。应用程序可以重新执行那个被强行退出的事务，现在这个事务可能就能够成功完成了，因为所有跟它竞争资源的事务都已经完成了。
JVM的处理：当一个Java线程集发生死锁时，“游戏”到此结束—这些线程永远不能再使用了。根据线程完成的不同工作，application可能完全停止或特定子系统停止，可能是性能收到影响。恢复application健康的唯一方式就是中止并重启，然后寄希望于不要再发生同样的事情。
1.1.1 锁顺序死锁
1.1.2 动态的锁顺序死锁
1.1.3 协作对象间的死锁
1.1.4 开放调用
1.1.5 资源死锁
1.2 避免和诊断死锁
1.2.1 尝试定时的锁
1.2.2 通过线程转储分析死锁
1.3.其他活跃度危险
1.3.1 饥饿
1.3.2 弱响应性
1.3.3 活锁
2.性能和可伸缩性
2.1 内存同步
2.2 阻塞
2.3 减少锁的竞争
2.3.1 缩小锁的范围（“快进快出”）
2.3.2 减少锁的粒度
2.3.3 分离锁
2.3.4 避免热点域
2.3.5 独占锁的替代方式
2.3.6 减少上下文的切换
2.3.7 向对象池说“不”
======================高级部分==============================
3.Lock、ReentrantLock和Synchronized
3.1 可轮询和可定时的锁请求
3.1 可中断的锁获取操作
4.原子变量与非阻塞同步机制
5. JMM--Java存储模型
