生產環境的伺服器突然訪問無響應，而我的服務是用來接收上游推送資料用的，功能也是最近新上線的；
heap configuration:
minheapfreeratio = 40
maxheapfreeratio = 70
maxheapsize = 8589934592 (8192.0mb)
newsize = 1073741824 (1024.0mb)
maxnewsize = 1073741824 (1024.0mb)
oldsize = 7516192768 (7168.0mb)
newratio = 2
survivorratio = 8
metaspacesize = 21807104 (20.796875mb)
compressedclassspacesize = 1073741824 (1024.0mb)
maxmetaspacesize = 17592186044415 mb
g1heapregionsize = 0 (0.0mb)
heap usage:
new generation (eden + 1 survivor space):
capacity = 966393856 (921.625mb)
used = 133072768 (126.9080810546875mb)
free = 833321088 (794.7169189453125mb)
13.770034564458157% used
eden space:
capacity = 859045888 (819.25mb)
used = 115850424 (110.48357391357422mb)
free = 743195464 (708.7664260864258mb)
13.48594127721382% used
from space:
capacity = 107347968 (102.375mb)
used = 17222344 (16.42450714111328mb)
free = 90125624 (85.95049285888672mb)
16.043474618914072% used
to space:
capacity = 107347968 (102.375mb)
used = 0 (0.0mb)
free = 107347968 (102.375mb)
0.0% used
concurrent mark-sweep generation:
capacity = 7516192768 (7168.0mb)
used = 76538880 (72.9931640625mb)
free = 7439653888 (7095.0068359375mb)
1.018319811139788% used
排查服務日誌時發現從某一時間點之後，服務乙個請求都沒有收到，只好查一下當前服務的請求數：
netstat -an |grep -i 8035 |wc -l節點2：
我們服務是雙節點部署，容器是jetty，可見大部分的請求的狀態已經變為close_wait；
檢視監控系統上的等待tcp情況：
補充colse_wait是什麼
客戶端向服務端傳送斷開連線請求，這是客供端傳送乙個fin給服務端；這是乙個正常的揮手過程，而我們大量的請求狀態處於close_wait，可能的原因就是我們服務正在處理業務沒有完畢，造成了大量請求阻塞，而我上游系統的http請求也會有超時限制，所以超時之後，上游系統就會傳送斷開連線fin；服務端收到fin後回應ack，此時服務端就會處於close_wait狀態；
服務端業務處理完畢之後，服務端向客戶端傳送fin；
客戶端返回給伺服器乙個確認ack狀態；
好了，回到問題排查的過程中；
既然可能是程式問題造成請求一直處理業務處理中無法結束，通過服務日誌排查**問題；
介面的邏輯大致如下：
從上圖可以看出有乙個明顯的問題，事務的控制範圍過大；
隱藏著的另外乙個bug就是分布式鎖這塊；
從現有的日誌中看出，上游傳資料已經違背了當初的規則，當初說介面是一次傳送乙個主行記錄和多行明細，而上游上線前因為需求變化改為了乙個主行乙個明細迴圈併發呼叫我們的介面； 當介面傳送的都是同乙個倉庫下的資訊時
這會導致：
因為是同乙個倉庫，分布式鎖的key正好是倉庫為維度的，這會導致執行緒a在修改完庫存之後，資料庫對當前庫存記錄加tx鎖，在進行同步下游系統時，執行緒b搶占到了分布式鎖，但修改庫存時，會導致無法提交事務，因為上個請求的tx鎖沒有提交事務；
當併發量一大起來，執行緒a的減少可用量請求可能一直獲取不到鎖，就導致它的更新庫存sql卡死，造成後續修改相同記錄的請求全部阻塞；
後端伺服器請求
設定 uri uri urlthree new uri 設定byte 陣列 byte sssss system.text.encoding.utf8.getbytes fdsafdsafdsa 另外新增一種byte與string 轉換 一般電腦程式都是按照byte儲存位元組 string sssss...
減少linux伺服器大量TIME WAIT
將專案部署到linux上後，發現系統有大量的time wait狀態的鏈結，大量time wait狀態的鏈結不能被及時 導致的結果就是系統可用socket被耗盡而無法處理新的請求。對於http協議的短連線請求，應該要防止產生大量的time wait，我們可以通過設定linux網路引數來達到目的，步驟如...
伺服器大量TIME WAIT解決方法
剛看伺服器出現大量的time wait鏈結 netstat an 10.76.28.131 3306 10.76.28.131 30443 time wait 10.76.28.131 3306 10.76.28.13130444 time wait 192.168.12.13 3306 192.1...