目錄：
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存儲模型
