一年前，本人有幸負責公司核心專案的優化。隨著公司業務的增長，專案處理量也越來越大。
一次818大促甚至導致一台伺服器滿負荷運作。於是，高併發改造被提上日程。
乾貨開始：
技術實現上有三個重點：非同步化（一般使用mq）、快取（一般使用redis）、多執行緒
乙個功能併發量上大的提公升，是需要業務和技術上共同去努力實現的。重點在於業務上的解耦，技術上的非同步化。
假設乙個核心系統分為三個部分（前台、中臺、後台）
1、前台負責所有外部系統的http請求，這裡只進行簡單的邏輯處理，盡量去繞過資料庫這些笨重的服務，將訊息存入mq，然後通知外部系統成功結果。
2、中臺負責處理前台mq中訊息，運算元據庫，進行一些費時的操作，所以為了提公升處理速度，一般使用多執行緒 + 快取。如果處理失敗，則需要記錄下來進行重試，重試一定次數依然失敗，則需要在後台中顯示進行人工操作。
3、後台負責人工異常處理。
這樣設計部署的話，想要提高併發量，只需要前台和中颱橫向擴充機器即可，所有的壓力壓在了負載均衡機器和mq中介軟體那裡。一般瓶頸都在於中介軟體那塊。
很多公司使用kafka來提公升mq中介軟體的速度。但是kafka相對於其他的mq方案更加的不安全，需要額外的方案優化和資料恢復措施。
還有很多細節方面：資源懶載入、資源預熱（防止第一次訪問超時）等等
專案改造半年之後，單台伺服器tps在五萬左右，雖然沒有達到預期的十萬大關，不過大促倒也可以輕鬆應對了。
高併發 並行，多執行緒 同步非同步，鎖
1 為什麼需要並行？業務要求 業務需要邏輯執行單元，想到用執行緒充當這個單元 效能並行 比序列 複雜的多。2 幾個重要的概念 同步 synchronous 和非同步 asynchronous 相對於方法呼叫而言。同步等待方法返回。非同步呼叫瞬間返回，呼叫不一定完成，在後台另起乙個執行緒慢慢的去做它的...
多執行緒高併發
修飾靜態方法鎖的是class，非靜態鎖方法鎖的是this，只有拿到這個物件才可以繼續執行 synchronized是可重入鎖 執行緒1的方法1呼叫執行緒2的方法2，判斷是同一把鎖，在同乙個執行緒，可以呼叫。synchronized的鎖公升級 hotsport 鎖公升級過程 保證執行緒可見性 mesi...
多執行緒高併發
個人總結，帶有個人主觀，請選擇性 1，實現 runable 2，使用 thread 3，執行緒池建立 executorse newcachedthreadpool 其實哪有那麼多建立方式，本質上都是實現了runable 介面。只列出大部分使用的方法，並未代表所有執行緒方法，後續會新增實際的例子，以供...