在乙個task提交到執行緒池時，假設可以被執行緒池中的乙個執行緒執行，則進行以下過程：
exeute ---》addworker（runnable command， boolean core）---》workers.add（w），啟動執行緒執行任務（獲取全域性鎖reentrantlock mainlock）
具體原始碼如下：
public void execute(runnable command)
//如果當前執行的執行緒數大於等於corepoolsize或者執行緒建立失敗
//則把當前任務放入工作佇列
if (isrunning(c) && workqueue.offer(command))
//如果執行緒池任務無法加入到工作佇列（說明工作佇列滿了）
//建立乙個執行緒執行任務。如果新建立後當前執行的執行緒數大於
//maximumpoolsize則拒絕執行任務
else if (!addworker(command, false))
reject(command);
}
private boolean addworker(runnable firsttask, boolean core)
} finally
if (workeradded)
}} finally
return workerstarted;
}
上述**中：
w = new worker(firsttask);
final thread t = w.thread;
worker實現了runnable介面，裡面定義了乙個final變數thread thread
worker的建構函式為：
worker(runnable firsttask)public void run()final void runworker(worker w) finally
}completedabruptly = false;
} finally
}
看完上述**後，我們可以得出：
執行緒池建立執行緒需要獲取mainlock這個全域性鎖，影響併發效率，阻塞佇列可以很好的緩衝。
另外一方面，如果新任務的到達速率超過了執行緒池的處理速率，那麼新到來的請求將累加起來，這樣的話將耗盡資源。
為什麼要使用訊息佇列
參考 訊息佇列本身有確認訊息被正確消費的機制 4.2message acknowledgment訊息確認 為了保證資料不被丟失,rabbitmq支援訊息確認機制,為了保證資料能被正確處理而不僅僅是被consumer收到,那麼我們不能採用no ack，而應該是在處理完資料之後傳送ack.在處理完資料之...
為什麼要使用訊息佇列？
在實際的專案實踐中，訊息佇列有的使用還是比較常用的，有時在想訊息佇列的好處是什麼，使用mq能帶來什麼好處。在說之前，目前市場主流的幾種mq activemq，rabbitmq，rocketmq,kafka 關於mq的入門就不說了，可以找下教程，寫個demo測試一下就好了，還是比較簡單的。先上張圖了解...
為什麼要使用訊息佇列
緩衝和削峰 上游資料時有突發流量，下游可能扛不住，或者下游沒有足夠多的機器來保證冗餘，kafka在中間可以起到乙個緩衝的作用，把訊息暫存在kafka中，下游服務就可以按照自己的節奏進行慢慢處理。解耦和擴充套件性 專案開始的時候，並不能確定具體需求。訊息佇列可以作為乙個介面層，解耦重要的業務流程。只需...