0、併發環境下進行編程，經常需要使用鎖機制來同步多線程間的操作，保證共享資源（共享變量）的互斥訪問
a、加鎖會帶來性能上的損壞
b、加鎖本身不會帶來多少的性能消耗，性能主要是在線程的獲取鎖的過程
c、當只有一個線程競爭鎖，因爲不存在多線程競爭的情況，那麼JVM就會進行鎖優化
d、JVM進行鎖優化後，這時你的加鎖行爲，帶來的性能消耗是極低的
e、所以，我們只要規範加鎖的操作，優化鎖的使用方法，就可以避免不必要的線程競爭（減少線程獲取鎖的過程），不僅可以提高程序性能，也能避免不規範加鎖可能造成線程死鎖問題，提高程序健壯性
闡述幾種鎖優化的思路
一、儘量不要鎖住方法（鎖的範圍越小越好，最好就鎖共享變量被操作的代碼）
在實例方法上加鎖時，線程獲得的是該方法所在對象的對象鎖。此時整個對象都會被鎖住。如果這個對象提供的多個同步方法是針對不同業務的，那麼由於整個對象已經被鎖住，當一個業務邏輯再處理時，其他不相關的業務線程也必須處於BLOCKED狀態。下面的例子展示了這種情況：
LockMethod類包含兩個同步方法，分別在兩種業務處理中被調用：
public class LockMethod {
public synchronized void busiA() {
for (int i = 0; i < 10000; i++) {
System.out.println(Thread.currentThread().getName() + "deal with bussiness A:"+i);
}
}
public synchronized void busiB() {
for (int i = 0; i < 10000; i++) {
System.out.println(Thread.currentThread().getName() + "deal with bussiness B:"+i);
}
}
}
BUSSA是線程類，用來處理A業務，調用的是LockMethod的busiA（）方法：
public class BUSSA extends Thread {
LockMethod lockMethod;
void deal(LockMethod lockMethod){
this.lockMethod = lockMethod;
}
@Override
public void run() {
super.run();
lockMethod.busiA();
}
}
BUSSB是線程類，用來處理B業務，調用的是LockMethod的busiB（）方法：
public class BUSSB extends Thread {
LockMethod lockMethod;
void deal(LockMethod lockMethod){
this.lockMethod = lockMethod;
}
@Override
public void run() {
super.run();
lockMethod.busiB();
}
}
TestLockMethod類，使用線程BUSSA與BUSSB進行業務處理：
public class TestLockMethod extends Thread {
public static void main(String[] args) {
LockMethod lockMethod = new LockMethod();
BUSSA bussa = new BUSSA();
BUSSB bussb = new BUSSB();
bussa.deal(lockMethod);
bussb.deal(lockMethod);
bussa.start();
bussb.start();
}
}
運行程序，可以看到在線程bussa 執行的過程中，bussb是不能夠進入函數 busiB()的，因爲此時lockMethod 的對象鎖被線程bussa獲取了（是啊，沒錯）
二、縮小同步代碼塊，只鎖數據（只鎖共享變量）
有時候爲了編程方便，有些人會synchnoized很大的一塊代碼，如果這個代碼塊中的某些操作與共享資源（共享變量）並不相關，那麼應當把它們放到同步塊的外邊，避免長時間的持有鎖，造成其他線程一直處於BLOCKED狀態。尤其是一些循環操作、同步I/O操作。不止是在代碼的行數範圍上縮小同步塊，在執行邏輯上，也應該縮小同步塊，例如多加一些條件判斷
a、符合條件的再進行同步，而不是同步之後再進行條件判斷，儘量減少不必要的進入同步塊的邏輯
三、鎖中儘量不要再包含鎖（別玩重入鎖）
這種情況經常發生，線程在得到了A鎖之後，在同步方法塊中調用了另外對象的同步方法，獲得了第二個鎖，這樣可能導致一個調用堆棧中有多把鎖的請求，多線程情況下可能會出現很複雜、難以分析的異常情況，導致死鎖的發生。下面的代碼顯示了這種情況：
synchronized(A){
synchronized(B){
}
}
或是在同步塊中調用了同步方法：
synchronized(A){
B b = objArrayList.get(0);
b.method(); //這是一個同步方法
}
解決的辦法是跳出來加鎖（第一個鎖釋了，再加第二個鎖），不要包含加鎖：
{
B b = null;
synchronized(A){
b = objArrayList.get(0);
}
b.method();
}
四、將鎖私有化，在內部管理鎖（對象鎖私有，不要讓對象鎖引用到處傳遞）
把鎖作爲一個私有的對象，外部不能拿到這個對象，更安全一些。對象可能被其他線程直接進行加鎖操作，此時線程便持有了該對象的對象鎖，例如下面這種情況：
class A {
public void method1() {
}
}
class B {
public void method1() {
A a = new A();
synchronized (a) { //直接進行加鎖
a.method1();
}
}
}
這種使用方式下，對象a的對象鎖被外部所持有，讓這把對象鎖在外部多個地方被使用是比較危險的，對代碼的邏輯流程閱讀也造成困擾。一種更好的方式是在類的內部自己管理鎖，外部需要同步方案時，也是通過接口方式來提供同步操作：
class A {
private Object lock = new Object();
public void method1() {
synchronized (lock){
}
}
}
class B {
public void method1() {
A a = new A();
a.method1();
}
}
五、進行適當的鎖分解
考慮下面這段程序：
public class GameServer {
public Map<String, List<Player>> tables = new HashMap<String, List<Player>>();
public void join(Player player, Table table) {
if (player.getAccountBalance() > table.getLimit()) {
synchronized (tables) {
List<Player> tablePlayers = tables.get(table.getId());
if (tablePlayers.size() < 9) {
tablePlayers.add(player);
}
}
}
}
public void leave(Player player, Table table) {/*省略*/}
public void createTable() {/*省略*/}
public void destroyTable(Table table) {/*省略*/}
}
在這個例子中，join方法只使用一個同步鎖，來獲取tables中的List<Player>對象，然後判斷玩家數量是不是小於9，如果是，就調增加一個玩家。當有成千上萬個List<Player>存在tables中時，對tables鎖的競爭將非常激烈。在這裏，我們可以考慮進行鎖的分解：快速取出數據之後，對List<Player>對象進行加鎖，讓其他線程可快速競爭獲得tables對象鎖：
public class GameServer {
public Map<String, List<Player>> tables = new HashMap<String, List<Player>>();
public void join(Player player, Table table) {
if (player.getAccountBalance() > table.getLimit()) {
List<Player> tablePlayers = null;
synchronized (tables) {
tablePlayers = tables.get(table.getId());
}
synchronized (tablePlayers) {
if (tablePlayers.size() < 9) {
tablePlayers.add(player);
}
}
}
}
public void leave(Player player, Table table) {/*省略*/}
public void createTable() {/*省略*/}
public void destroyTable(Table table) {/*省略*/}
}
