⑴ 在java中，死鎖形成的原因是
死鎖是進程死鎖的簡稱，是由Dijkstra於1965年研究銀行家演算法時首先提出來的。它是計算機操作系統乃至並發程序設計中最難處理的問題之一。實際上，死鎖問題不僅在計算機系統中存在，在我們日常生活中它也廣泛存在。
1.什麼是死鎖
我們先看看這樣一個生活中的例子：在一條河上有一座橋，橋面較窄，只能容納一輛汽車通過，無法讓兩輛汽車並行。如果有兩輛汽車A和B分別由橋的兩端駛上該橋，則對於A車來說，它走過橋面左面的一段路（即佔有了橋的一部分資源），要想過橋還須等待B車讓出右邊的橋面，此時A車不能前進；對於B車來說，它走過橋面右邊的一段路（即佔有了橋的一部分資源），要想過橋還須等待A車讓出左邊的橋面，此時B車也不能前進。兩邊的車都不倒車，結果造成互相等待對方讓出橋面，但是誰也不讓路，就會無休止地等下去。這種現象就是死鎖。如果把汽車比做進程，橋面作為資源，那麽上述問題就描述為：進程A佔有資源R1，等待進程B佔有的資源Rr；進程B佔有資源Rr，等待進程A佔有的資源R1。而且資源R1和Rr只允許一個進程佔用，即：不允許兩個進程同時佔用。結果，兩個進程都不能繼續執行，若不採取其它措施，這種循環等待狀況會無限期持續下去，就發生了進程死鎖。
在計算機系統中，涉及軟體，硬體資源都可能發生死鎖。例如：系統中只有一台CD-ROM驅動器和一台列印機，某一個進程佔有了CD-ROM驅動器，又申請列印機；另一進程佔有了列印機，還申請CD-ROM。結果，兩個進程都被阻塞，永遠也不能自行解除。
所謂死鎖，是指多個進程循環等待它方佔有的資源而無限期地僵持下去的局面。很顯然，如果沒有外力的作用，那麽死鎖涉及到的各個進程都將永遠處於封鎖狀態。從上面的例子可以看出，計算機系統產生死鎖的根本原因就是資源有限且操作不當。即：一種原因是系統提供的資源太少了，遠不能滿足並發進程對資源的需求。這種競爭資源引起的死鎖是我們要討論的核心。例如：消息是一種臨時性資源。某一時刻，進程A等待進程B發來的消息，進程B等待進程C發來的消息，而進程C又等待進程A發來的消息。消息未到，A，B，C三個進程均無法向前推進，也會發生進程通信上的死鎖。另一種原因是由於進程推進順序不合適引發的死鎖。資源少也未必一定產生死鎖。就如同兩個人過獨木橋，如果兩個人都要先過，在獨木橋上僵持不肯後退，必然會應競爭資源產生死鎖；但是，如果兩個人上橋前先看一看有無對方的人在橋上，當無對方的人在橋上時自己才上橋，那麽問題就解決了。所以，如果程序設計得不合理，造成進程推進的順序不當，也會出現死鎖。
2.產生死鎖的必要條件
從以上分析可見，如果在計算機系統中同時具備下面四個必要條件時，那麽會發生死鎖。換句話說，只要下面四個條件有一個不具備，系統就不會出現死鎖。
〈1〉互斥條件。即某個資源在一段時間內只能由一個進程佔有，不能同時被兩個或兩個以上的進程佔有。這種獨占資源如CD-ROM驅動器，列印機等等，必須在佔有該資源的進程主動釋放它之後，其它進程才能佔有該資源。這是由資源本身的屬性所決定的。如獨木橋就是一種獨占資源，兩方的人不能同時過橋。
〈2〉不可搶占條件。進程所獲得的資源在未使用完畢之前，資源申請者不能強行地從資源佔有者手中奪取資源，而只能由該資源的佔有者進程自行釋放。如過獨木橋的人不能強迫對方後退，也不能非法地將對方推下橋，必須是橋上的人自己過橋後空出橋面（即主動釋放佔有資源），對方的人才能過橋。
〈3〉佔有且申請條件。進程至少已經佔有一個資源，但又申請新的資源；由於該資源已被另外進程佔有，此時該進程阻塞；但是，它在等待新資源之時，仍繼續佔用已佔有的資源。還以過獨木橋為例，甲乙兩人在橋上相遇。甲走過一段橋面（即佔有了一些資源），還需要走其餘的橋面（申請新的資源），但那部分橋面被乙佔有（乙走過一段橋面）。甲過不去，前進不能，又不後退；乙也處於同樣的狀況。
〈4〉循環等待條件。存在一個進程等待序列{P1，P2，...，Pn}，其中P1等待P2所佔有的某一資源，P2等待P3所佔有的某一源，......，而Pn等待P1所佔有的的某一資源，形成一個進程循環等待環。就像前面的過獨木橋問題，甲等待乙佔有的橋面，而乙又等待甲佔有的橋面，從而彼此循環等待。
上面我們提到的這四個條件在死鎖時會同時發生。也就是說，只要有一個必要條件不滿足，則死鎖就可以排除。
8.2 死鎖的預防
前面介紹了死鎖發生時的四個必要條件，只要破壞這四個必要條件中的任意一個條件，死鎖就不會發生。這就為我們解決死鎖問題提供了可能。一般地，解決死鎖的方法分為死鎖的預防，避免，檢測與恢復三種（注意：死鎖的檢測與恢復是一個方法）。我們將在下面分別加以介紹。
死鎖的預防是保證系統不進入死鎖狀態的一種策略。它的基本思想是要求進程申請資源時遵循某種協議，從而打破產生死鎖的四個必要條件中的一個或幾個，保證系統不會進入死鎖狀態。
⑵ 從偏向鎖到輕量級鎖：Java鎖的演進與性能分析
在並發編程中，鎖是一個重要的概念。本文將探討一種特殊類型的鎖：偏向鎖。偏向鎖是偏向於鎖的當前持有者的，如果當前持有鎖的線程再次請求鎖，那麼無需再進行任何同步操作。這種鎖策略適用於幾乎沒有真正線程競爭的情況，即一個線程連續多次獲取同一把鎖。在實際的 Java 編程中，偏向鎖可以幫助提升系統性能。
假設我們正在編寫一個電商應用，需要記錄商品的銷售數量。在大多數情況下，這個數據可能都會被同一個線程（如更新資料庫的線程）訪問和修改。這時，我們可以使用偏向鎖來提高性能。在並發編程中，鎖的管理通常是性能瓶頸的關鍵因素。偏向鎖是一種優化鎖性能的策略，其核心思想是減少不必要的鎖競爭開銷。當一個鎖被一個線程頻繁獲取時，JVM 將這個鎖"偏向"到這個線程，意味著在此後的幾次嘗試中，該線程可以無需同步操作就能獲取這個鎖。這大大減少了鎖獲取和釋放的開銷，提升了程序的運行效率。
輕量級鎖在 Java 並發編程中應用廣泛，特別是在多線程環境下對資源進行保護和同步時。它的設計目標是在沒有真正的競爭情況下減少無競爭同步的性能開銷，使得多個線程並發訪問同步代碼時能夠展現出更高的性能。輕量級鎖在 Java 中的應用場景廣泛，例如在我們之前提到的示例代碼中，lock 對象上的鎖在沒有競爭的情況下會被 JVM 優化為輕量級鎖。
輕量級鎖的性能優勢主要源於它在無競爭情況下能夠通過 CAS 操作成功獲取鎖，而無需進行線程切換和調度。然而，如果發生了鎖競爭，輕量級鎖會膨脹為重量級鎖，這時會引入線程切換和調度的開銷。選擇使用哪種鎖優化手段，需要根據實際的程序行為來決定。有時候，輕量級鎖和偏向鎖的性能表現可能並不如預期，這時候我們就需要深入理解並發的性質，通過合理的優化來提高性能。
在 Java 的演進過程中，鎖技術一直在優化，目的就是為了提高並發性能。我們看到了從 Monitor 鎖向偏向鎖和輕量級鎖的轉變，以及引入自旋鎖和自適應自旋等機制。未來 Java 鎖可能會繼續朝著減少線程阻塞和喚醒的開銷，以及適應多核處理器的並發模型等方向發展。學習和實踐 Java 鎖的優化和發展是一個持續的過程，它需要我們不斷地學習和實踐，以便更好地理解和使用這些技術，提高我們程序的性能。