由於資源競爭或通訊問題造成的乙個阻塞現象，若無外力作用無法推進下去.
當執行緒互相持有對方所需要的資源時，會互相等待對方釋放資源，如果執行緒都不主動釋放所占有的資源，將產生死鎖。
1 < 競爭資源 < 搶占資源的執行緒數
如果競爭資源為1時，不存在死鎖問題，因為不是不是a執行緒占有就是b執行緒占有，不會相互等待對方釋放
import com.enjoy.demo.p1.ch1.class1.sleeptools;
/** * @author: billyu
* @description:演示普通的死鎖和解決
* @date: created in 13:29 2019-03-15.
* ** 死鎖：由於資源競爭或通訊問題造成的乙個阻塞現象，若無外力作用無法推進下去
* 1 < 競爭資源 < 搶占資源的執行緒數
* */
public class normaldeadlock }}
/*** 先拿第二個鎖，再拿第乙個鎖
*/private static void secondtofirst() throws interruptedexception}}
/*** 執行先拿第二個鎖，再拿第乙個鎖
*/private static class testthread extends thread
@override
public void run()catch (interruptedexception e)}}
public static void main(string args) catch (interruptedexception e)}}
subtestthread get second
testdeadlock get first
通過jps查詢應用的id,再通過jstack id檢視應用的鎖的持有情況（持有的鎖 等待的鎖）。
1.保證加鎖的順序
比如物件的hashcode,可以使用system.identityhashcode() 系統提供的native方法，兩個物件identityhashcode相同的概率只有千萬分之一。如果物件的identityhashcode相同，可以再在外面加乙個總的鎖，如果不同就以identityhashcode從小到大獲取鎖的順序進行。
2.reentrantlock
嘗試獲取鎖，直到獲取到所有的鎖為止，有鎖競爭時釋放鎖。
可能會導致活鎖的情況。可休眠隨機時長，避免活鎖的發生。
嘗試拿鎖的機制中，發生多個執行緒之間相互謙讓，不斷發生拿鎖，釋放鎖的過程。
解決辦法：每個執行緒休眠隨機時長，錯開拿鎖的時間
日誌排查問題總結
寫在前面 因為公司負責的專案流程鏈路很長，經常需要排查問題定位問題。目前專案是把每個service的方法前後都加上了入參和返回值的列印。接管專案後，總結了一下通過日誌定位問題的經驗，希望以後排查問題能有一些幫助。第二版 運單後台排查問題的方法總結 邏輯熟悉時 4.再根據測試 現場人員描述的描述以及自...
排查問題思路（一）
問題前提 今天回歸測試用例時，上午回歸用例正常，下午回歸用例98 的用例均報錯，返回空指標異常，伺服器執行正常未宕機。排查思路 1.重跑用例，檢視日誌，因為是錄製的流量，很多資料都是自動mock了，所以無法排查鏈路上是否存在問題。2.重跑全鏈路用例，發現服務基本正常，無問題，排除鏈路上的問題，問題可...
linux定時任務排查問題
閱讀本文時，請先閱讀 定時任務的配置 場景使用 當乙個處理需要定時任務處理時，但是卻沒有達到預期的效果的時候，可以這樣排查是否是定時任務出問題了！原則 無論是什麼，凡是涉及服務的必須有日誌！1.使用ssh等工具連上linux伺服器，使用命令檢視linux的定時任務是否正常執行 如果不正常執行手動呼叫...