㈠ java多線程,對象鎖是什麼概念
java線程:
1．線程中一些基本術語和概念
1.1線程的幾個狀態
初始化狀態
就緒狀態
運行狀態
阻塞狀態
終止狀態
1.2 Daemon線程
Daemon線程區別一般線程之處是：主程序一旦結束，Daemon線程就會結束。
1.3鎖的定義
為了協調多個並發運行的線程使用共享資源才引入了鎖的概念。
1.4死鎖
任何多線程應用程序都有死鎖風險。當一組線程中的每一個都在等待一個只
有該組中另一個線程才能引起的事件時，我們就說這組線程死鎖了。換一個說法
就是一組線程中的每一個成員都在等待別的成員佔有的資源時候，就可以說這組
線程進入了死鎖。死鎖的最簡單情形是：線程 A 持有對象 X 的獨占鎖，並且
在等待對象 Y 的鎖，而線程 B 持有對象 Y 的獨占鎖，卻在等待對象 X 的鎖。
除非有某種方法來打破對鎖的等待（Java 鎖定不支持這種方法），否則死鎖的線
程將永遠等下去。
1.5.Java對象關於鎖的幾個方法
1.5.1 wait方法
wait方法是java根對象Object含有的方法，表示等待獲取某個鎖。在wait方法進入前，會釋放相應的鎖，在wait方法返回時，會再次獲得某個鎖。
如果wait()方法不帶有參數，那隻有當持有該對象鎖的其他線程調用了notify或者notifyAll方法，才有可能再次獲得該對象的鎖。
如果wait()方法帶有參數，比如：wait(10)，那當持有該對象鎖的其他線程調用了notify或者notifyAll方法，或者指定時間已經過去了，才有可能再次獲得該對象的鎖。
參考 thread.lock.SleepAndWait
1.5.2 notify/notifyAll方法
這里我就不再說明了。哈哈，偷點懶。
1.5.3 yield方法
yield()會自動放棄CPU，有時比sleep更能提升性能。
1.6鎖對象(實例方法的鎖)
在同步代碼塊中使用鎖的時候，擔當鎖的對象可以是這個代碼所在對象本身或者一個單獨的對象擔任，但是一定要確保鎖對象不能為空。如果對一個null對象加鎖，會產生異常的。原則上不要選擇一個可能在鎖的作用域中會改變值的實例變數作為鎖對象。
鎖對象,一種是對象自己擔任，一種是定義一個普通的對象作為private property來擔任，另外一種是建立一個新的類，然後用該類的實例來擔任。
參考 :
thread.lock.UseSelfAsLock，使用對象自己做鎖對象
thread.lock.UseObjAsLock 使用一個實例對象作鎖對象
thread.lock.UseAFinalObjAsLock使用常量對象作為一個鎖對象
1.7類鎖
實例方法存在同步的問題，同樣，類方法也存在需要同步的情形。一般類方法的類鎖是一個static object來擔任的。當然也可以採用類本身的類對象來作為類鎖。
一個類的實例方法可以獲得該類實例鎖，還可以嘗試去訪問類方法，包含類同步方法，去獲得類鎖。
一個類的類方法，可以嘗試獲得類鎖，但是不可以嘗試直接獲得實例鎖。需要先生成一個實例，然後在申請獲得這個實例的實例鎖。
參考
thread.lock.UseStaticObjAsStaticLock 使用類的屬性對象作為類鎖。
thread.lock.UseClassAsStaticLock使用類的類對象作為類鎖
1.8.線程安全方法與線程不安全方法
如果一個對象的所有的public方法都是同步方法，也就是說是public方法是線程安全的，那該對象的private方法，在不考慮繼承的情況下，可以設置為不是線程安全的方法。
參考 thread.lock.SynMethrodAndNotSynMethrod
1.9類鎖和實例鎖混合使用
在實例方法中混合使用類鎖和實例鎖；可以根據前面說的那樣使用實例鎖和類鎖。
在類方法中混合使用類鎖和實例鎖，可以根據前面說的那樣使用類鎖，為了使用實例鎖，先得生成一個實例，然後實例鎖。
參考 thread.lock.StaticLockAndObjLock
1.10鎖的粒度問題。
為了解決對象鎖的粒度過粗，會導死鎖出現的可能性加大，鎖的粒度過細，會程序開發維護的工作加大。對於鎖的粒度大小，這完全要根據實際開發需要來考慮，很難有一個統一的標准。
1.11.讀寫鎖
一個讀寫鎖支持多個線程同時訪問一個對象，但是在同一時刻只有一個線程可以修改此對象，並且在訪問進行時不能修改。
有2種調度策略，一種是讀鎖優先，另外就是寫鎖優先。
參考 thread.lock.ReadWriteLock
1.12 volatile
在Java中設置變數值的操作，除了long和double類型的變數外都是原子操作，也就是說，對於變數值的簡單讀寫操作沒有必要進行同步。這在JVM 1.2之前，Java的內存模型實現總是從主存讀取變數，是不需要進行特別的注意的。而隨著JVM的成熟和優化，現在在多線程環境下volatile關鍵字的使用變得非常重要。在當前的Java內存模型下，線程可以把變數保存在本地內存（比如機器的寄存器）中，而不是直接在主存中進行讀寫。這就可能造成一個線程在主存中修改了一個變數的值，而另外一個線程還繼續使用它在寄存器中的變數值的拷貝，造成數據的不一致。要解決這個問題，只需要像在本程序中的這樣，把該變數聲明為volatile（不穩定的）即可，這就指示JVM，這個變數是不穩定的，每次使用它都到主存中進行讀取。一般說來，多任務環境下各任務間共享的標志都應該加volatile修飾。
2．線程之間的通訊
在其他語言中，線程之間可以通過消息隊列，共享內存，管道等方式來實現
線程之間的通訊，但是java中可以不採用這樣方式，關注的是線程之間的同步。
只要保證相關方法運行的線程安全，信息共享是自然就可以顯現了。
2.1屏障
屏障就是這樣的一個等待點: 一組線程在這一點被同步，這些線程合並各自的結果或者運行到整體任務的下一階段。
參考：
thread.lock. BarrierUseExample
thread.lock.Barrier
2.2.鎖工具類
提供對線程鎖的獲取，釋放功能。展示了鎖的獲取釋放過程。可以作為一個工具類來使用。
參考：thread.lock. BusyFlag
2.3.條件變數
條件變數是POSIX線程模型提供的一種同步類型，和java中的等待通知機制類似。
雖然java中已經有了等待通知機制，但是為了減少在notify/notifyAll方法中
線程調度的開銷，把一些不需要激活的線程屏蔽出去，引入了條件變數。
Java中2個（多個）條件變數可以是同一個互斥體（鎖對象）。
參考：thread.lock.CondVar 條件變數類
常見的應用情形：
一個鎖控制多個信號通道（例如：多個變數），雖然可以採用簡單java等待通知機制，但是線程調度效率不高，而且線程可讀性也不是太好，這時候可以採用創建一個鎖對象(BusyFlag實例)，同時使用這個BusyFlag實例來創建多個條件變數(CondVar 實例)。
經常使用到CondVar類的地方是緩沖區管理，比如：管道操作之類的。先創建一個BusyFlag實例，然後創建CondVar 實例，用這個條件變數描述緩沖區是否為空，另外創建CondVar 實例作條件變數述緩沖區是否滿。
現實中，馬路的紅綠燈，就可以採用條件變數來描述。
3. Java線程調度
3.1 Java優先順序
java的優先順序別共有10種，加上虛擬機自己使用的優先順序別=0這種，總共11種。
大多數情況來說，java線程的優先順序設置越高（最高=10），那線程越優先運行。
3.2. 綠色線程
線程運行在虛擬機內，操作系統根本不知道這類線程的存在。
線程是由虛擬機調度的。
3.3 本地線程
線程是由運行虛擬機的操作系統完成的。
3.4 Windows本地線程
操作系統，完全能夠看得到虛擬機內的每一個線程，同時虛擬機的線程和操作系統的線程是一一對應的。Java的線程調度室由操作系統底層線程決定的。
在win32平台下，windows線程只有6個優先順序別。和java線程優先順序別對應如下：
Java線程優先順序 Windows 95/nt/2000線程優先順序
0 THREAD_ PRIORITY_IDLE
1(Thread.MIN_PRIORITY) THREAD_ PRIORITY_LOWEST
2 THREAD_ PRIORITY_LOWEST
3 THREAD_ PRIORITY_BELOW_NORMAL
4 THREAD_ PRIORITY_BELOW_NORMAL
5 (Thread.NORM_PRIORITY) THREAD_ PRIORITY _NORMAL
6 THREAD_ PRIORITY _ABOVE_NORMAL
7 THREAD_ PRIORITY _ABOVE_NORMA
8 THREAD_ PRIORITY _HIGHEST
9 THREAD_ PRIORITY _HIGHEST
10 (Thread.MAX_PRIORITY) THREAD_ PRIORITY _CRITICAL
3.5線程優先順序倒置與繼承
如果一個線程持有鎖(假設該線程名字=ThreadA,優先順序別=5)，另外一個線程(假設該線程名字=ThreadB,優先順序別=7),現在該線程(ThreadA)處於運行狀態，但是線程ThreadB申請需要持有ThreadA所獲得的鎖，這時候，為了避免死鎖，線程A提高其運行的優先順序別（提高到ThreadB的優先順序別=7）,而線程ThreadB為了等待獲得鎖，降低線程優先順序別(降低到ThreadA原來的優先順序別=5).
上述的這種情況，對於ThreadA,繼承了ThreadB的優先順序別，這成為優先順序別的繼承；對於ThreadB暫時降低了優先順序別，成為優先順序別的倒置。
當然，一旦線程ThreadA持有的鎖釋放了，其優先順序別也會回到原來的優先順序別（優先順序別=5）。線程ThreadB獲得了相應的鎖，那優先順序別也會恢復到與原來的值(優先順序別=7)。
3.6循環調度
具有同樣優先順序的線程相互搶占成為循環調度。
4.線程池
創建一個線程也是需要一定代價的,為了降低這個代價，採用了和普通對象池的思想建立線程池，以供系統使用。
線程消耗包括內存和其它系統資源在內的大量資源。除了 Thread 對象所需的內存之外，每個線程都需要兩個可能很大的執行調用堆棧。除此以外，JVM 可能會為每個 Java 線程創建一個本機線程，這些本機線程將消耗額外的系統資源。最後，雖然線程之間切換的調度開銷很小，但如果有很多線程，環境切換也可能嚴重地影響程序的性能。
使用線程池的方式是，先建立對象池，然後申請使用線程，程序線程運行，運行完畢，把線程返回線程池。
使用線程池的風險：同步錯誤和死鎖，與池有關的死鎖、資源不足和線程泄漏。
大家有空可以研究一下tomcat的線程池實現原理思想。
實際上是tomcat已經在從線程池的使用線程時候加上了事件處理機制。
個人認為，線程池之類的實現，一般不要自己實現，因為自己實現主要是穩定性等方面可能作的不夠好。
可以參考 apache的jakarta-tomcat-5.5.6的相關代碼，具體是：
jakarta-tomcat-connectors\util\java\org\apache\tomcat\util\threads的相關代碼
5工作隊列
使用工作隊列的好處是不象直接使用線程池那樣，當線城池中沒有線程可以使用的時
候，使用者需要處於等待狀態，不能進行其他任務的處理。
工作隊列的工作原理是：
採用後台線程處理方式，客戶端把任務提交給工作隊列，工作隊列有一組內部可以工作線程，這些工作線程從工作隊列中取出任務運行，一個任務完成後，就從隊列獲取下一個任務進行處理。當工作隊列中沒有任務可以處理時候，工作線程就處於等待狀態，直到獲得新的任務時候，才進行新的處理。
㈡ 死循環，死遞歸和死鎖對CPU的消耗有什麼異同點
死循環，死遞歸和死鎖對CPU的消耗基本相同，但是產生的原因是不一樣的。
一、死循環。
例如在VB語言程序中，下列語句：
Do While i=1
print "*"
Loop
就是一個死循環，運行它將無休止地列印*號。
不存在一種演算法，對任何一個程序及相應的輸入數據，都可以判斷是否會出現死循環。因此，任何編譯系統都不做死循環檢查。
在設計程序時，若遇到死循環，我們可以通過按下Ctrl+Pause/Break的方法，結束死循環。
然而，在編程中死循環並不是一個需要避免的問題，相反，在實際應用中，經常需要用到死循環。例如，我們使用的Windows操作系統下的窗口程序中的窗口都是通過一個叫消息循環的死循環實現的。在單片機、嵌入式編程中也經常要用到死循環。在各類編程語言中，死循環都有多種實現的方法，以C語言為例，可分別使用while.for,goto實現。
二、死鎖。
兩個或兩個以上的進程在執行過程中，由於競爭資源或者由於彼此通信而造成的一種阻塞的現象，若無外力作用，它們都將無法推進下去。此時稱系統處於死鎖狀態或系統產生了死鎖，這些永遠在互相等待的進程稱為死鎖進程。
計算機系統中，如果系統的資源分配策略不當，更常見的可能是程序員寫的程序有錯誤等，則會導致進程因競爭資源不當而產生死鎖的現象。
在兩個或多個任務中，如果每個任務鎖定了其他任務試圖鎖定的資源，此時會造成這些任務永久阻塞，從而出現死鎖。例如：事務A 獲取了行 1 的共享鎖。事務 B 獲取了行 2 的共享鎖。
排他鎖，等待事務 B 完成並釋放其對行 2 持有的共享鎖之前被阻塞。
排他鎖，等待事務 A 完成並釋放其對行 1 持有的共享鎖之前被阻塞。
事務 B 完成之後事務 A 才能完成，但是事務 B 由事務 A 阻塞。該條件也稱為循環依賴關系：事務 A 依賴於事務 B，事務 B 通過對事務 A 的依賴關系關閉循環。
三、死機及其對策。
無論是死循環還是死鎖，都會造成電腦死機現象。
›電腦系統在工作中，有時候會出現滑鼠停滯、鍵盤不能輸入命令等情況，這時的系統已經不能接收任何命令，這種情況被稱為死機，死機可能是多種原因造成的，比如同時運行了過多的應用程序，程序的使用方法錯誤，電腦中某一硬體的損壞（比如硬碟或者內存）等都可能引起死機。解決的常用方法有：
同時按下鍵盤上的控制鍵加換檔鍵加刪除鍵，在顯示的列表中單擊【啟動任務管理器】命令，彈出【任務管理器】對話框，單擊出現問題的程序，再單擊【結束任務】按鈕，所選程序立即結束運行。在大多數情況下，都可以通過上述方法關閉已經失去響應的程序，並且可以繼續在Windows10中操作。
如果鍵盤已經不能輸入任何命令，可按下機箱上的復位鍵，幾秒鍾後電腦將重新啟動。
如果機箱上沒有復位鍵，可以直接按住機箱上的電源開關幾秒鍾，關閉電腦電源，稍後，再按機箱上的電源開關重新啟動電腦即可。
㈢ 加同步鎖為什麼會更耗費cpu資源
處理器中一個邏輯內核只允許一個線程佔用。
進程互斥，臨界區都是資源保護。
比如說a,b 兩個線程同時運行，它們都要存取變數var，a將var設置為20，然後繼續其他工作。
這時候b也要用了，它把var設置成自己需要的值。
過一會a又回來讀取var，這時候var已經不是a之前存進去的值了。
㈣ 網路流量消耗的是什麼資源
流量是每秒或者一定時間設備使用的數據量，這些資源是所上的網站提供的數據等經過壓縮封裝等處理後傳輸到你的PC，手機等設備上的，算是消耗的這種資源吧。
這種資源可以說是無限的，因為大家感覺總有訪問不盡的網站資源，使用不盡的網路數據。
有限的是我們手機每個月的流量（這個月一共可以用多少M），連接PC的網線、無線等的傳輸速度。。
僅個人理解~
㈤ 什麼是死鎖，怎樣引入死鎖
1.死鎖：如果一組進程中的每一個進程都在等待僅由該組進程中的其它進程才能引發的事件，那麼該組進程是死鎖的。
2.產生死鎖的原因：
（1）競爭不可搶占性資源。
（2）競爭可消耗資源。
當系統中供多個進程共享的資源如列印機，公用隊列等，其數目不足以滿足諸進程的需要時，會引起諸進程對資源的競爭而產生死鎖。12
（3）進程推進順序不當。
進程在運行過程中，請求和釋放資源的順序不當，也同樣會導致產生進程死鎖。12
如果系統資源充足，進程的資源請求都能夠得到滿足，死鎖出現的可能性就很低，否則就會因爭奪有限的資源而陷入死鎖。其次，進程運行推進順序與速度不同，也可能產生死鎖。
一個線程也可引起死鎖。12
3.產生死鎖的四個必要條件：
（1） 互斥條件：一個資源每次只能被一個進程使用。
（2） 請求和保持條件：一個進程因請求資源而阻塞時，對已獲得的資源保持不放。
（3） 不可搶占條件:進程已獲得的資源，在末使用完之前，不能強行剝奪，只能在進程使用完時由自己釋放。
（4） 循環等待條件:若干進程之間形成一種頭尾相接的循環等待資源關系。
這四個條件是死鎖的必要條件，只要系統發生死鎖，這些條件必然成立，而只要上述條件之一不滿足，就不會發生死鎖。因此可以寫下如下的預防死鎖的方法。
4.避免死鎖的方法：
（1）破壞「互斥」條件:就是在系統里取消互斥。若資源不被一個進程獨占使用，那麼死鎖是肯定不會發生的。但一般「互斥」條件是無法破壞的。因此，在死鎖預防里主要是破壞其他三個必要條件，而不去涉及破壞「互斥」條件。
（2）破壞「請求和保持」條件:在系統中不允許進程在已獲得某種資源的情況下，申請其他資源。即要想出一個辦法，阻止進程在持有資源的同時申請其他資源。
方法一：所有進程在運行之前，必須一次性地申請在整個運行過程中所需的全部資源。這樣，該進程在整個運行期間，便不會再提出資源請求，從而破壞了「請求」條件。系統在分配資源時，只要有一種資源不能滿足進程的要求，即使其它所需的各資源都空閑也不分配給該進程，而讓該進程等待。由於該進程在等待期間未佔有任何資源，於是破壞了「保持」條件。
該方法優點：簡單、易行且安全。
缺點：a.資源被嚴重浪費，嚴重惡化了資源的利用率。
b.使進程經常會發生飢餓現象。12
方法二：要求每個進程提出新的資源申請前，釋放它所佔有的資源。這樣，一個進程在需要資源S時，須先把它先前佔有的資源R釋放掉，然後才能提出對S的申請，即使它可能很快又要用到資源R。
（3）破壞「不可搶占」條件：允許對資源實行搶奪。
方法一：如果佔有某些資源的一個進程進行進一步資源請求被拒絕，則該進程必須釋放它最初佔有的資源，如果有必要，可再次請求這些資源和另外的資源。
方法二：如果一個進程請求當前被另一個進程佔有的一個資源，則操作系統可以搶占另一個進程，要求它釋放資源。只有在任意兩個進程的優先順序都不相同的條件下，該方法才能預防死鎖。
（4）破壞「循環等待」條件：將系統中的所有資源統一編號，進程可在任何時刻提出資源申請，但所有申請必須按照資源的編號順序（升序）提出。這樣做就能保證系統不出現死鎖。
利用銀行家演算法避免死鎖：
銀行家演算法:
設進程i提出請求Request[j]，則銀行家演算法按如下規則進行判斷。
(1) 如果Request[j]≤Need[i,j]，則轉向（2），否則認為出錯，因為它所需要的資源數已超過它所宣布的最大值。
(2) 如果Request[j]≤Available[j]，則轉向（3）；否則表示尚無足夠資源，Pi需等待。
(3) 假設進程i的申請已獲批准，於是修改系統狀態：
Available[j]=Available[j]-Request[i]
Allocation[i,j]=Allocation[i,j]+Request[j]
Need[i,j]=Need[i,j]-Request[j]
(4)系統執行安全性檢查，如安全，則分配成立；否則試探險性分配作廢，系統恢復原狀，進程等待。
安全性演算法：
(1) 設置兩個工作向量Work=Available；Finish[i]=False
(2) 從進程集合中找到一個滿足下述條件的進程，
Finish [i]=False;
Need[i,j]≤Work[j];
如找到，執行(3)；否則，執行(4)123456
(3) 設進程獲得資源，可順利執行，直至完成，從而釋放資源。
Work[j]=Work[j]+Allocation[i,j];
Finish[i]=True;
Go to step 2;123456
(4) 如所有的進程Finish[i]=true，則表示安全；否則系統不安全。
5.死鎖的解除：
一旦檢測出死鎖，就應立即釆取相應的措施，以解除死鎖。死鎖解除的主要兩種方法：
1) 搶占資源。從一個或多個進程中搶占足夠數量的資源，分配給死鎖進程，以解除死鎖狀態。
2) 終止（或撤銷）進程。終止（或撤銷）系統中的一個或多個死鎖進程，直至打破循環環路，使系統從死鎖狀態解脫出來。
總結：
一般情況下,如果同一個線程先後兩次調用lock,在第二次調用時,由於鎖已經被佔用,該線程會掛起等待別的線程釋放鎖,然而鎖正是被自己佔用著的,該線程又被掛起而沒有機會釋放鎖,因此就永遠處於掛起等待狀態了,這叫做死鎖(Deadlock)。另⼀一種典型的死鎖情形是這樣:線程A獲得了鎖1,線程B獲得了鎖2,這時線程A調⽤用lock試圖獲得鎖2,結果是需要掛起等待線程B釋放鎖2,而這時線程B也調⽤用lock試圖獲得鎖1,結果是需要掛起等待線程A釋放鎖1,於是線程A和B都永遠處於掛起狀態了。12
注意：
寫程序時應該盡量避免同時獲得多個鎖,如果一定有必要這么做,則有一個原則:如果所有線程在需要多個鎖時都按相同的先後順序(常見的是按Mutex變數的地址順序)獲得鎖,則不會出現死鎖。比如一個程序中用到鎖1、鎖2、鎖3,它們所對應的Mutex變數的地址是鎖1<鎖2<鎖3,那麼所有線程在需要同時獲得2個或3個鎖時都應該按鎖1、鎖2、鎖3的順序獲得。如果要為所有的鎖確定一個先後順序比較困難,則應pthread_mutex_trylock調用代替pthread_mutex_lock 調用,以免死鎖。
㈥ java多線程中的死鎖，活鎖，飢餓，無鎖都是什麼鬼
死鎖發生在當一些進程請求其它進程佔有的資源而被阻塞時。
另外一方面，活鎖不會被阻塞，而是不停檢測一個永遠不可能為真的條件。除去進程本身持有的資源外，活鎖狀態的進程會持續耗費寶貴的CPU時間。
最後，進程會處於飢餓狀態是因為持續地有其它優先順序更高的進程請求相同的資源。不像死鎖或者活鎖，飢餓能夠被解開。例如，當其它高優先順序的進程都終止時並且沒有更高優先順序的進程到達。
㈦ 龍珠激斗里兩把鎖是什麼資源
星龍之力，龍力之源，探索
㈧ 死鎖的產生原因是什麼
產生死鎖的原因主要是：
（1） 因為系統資源不足。
（2） 進程運行推進的順序不合適。
（3） 資源分配不當等。
如果系統資源充足，進程的資源請求都能夠得到滿足，死鎖出現的可能性就很低，否則
就會因爭奪有限的資源而陷入死鎖。其次，進程運行推進順序與速度不同，也可能產生死鎖。
產生死鎖的四個必要條件：
（1） 互斥條件：一個資源每次只能被一個進程使用。
（2） 請求與保持條件：一個進程因請求資源而阻塞時，對已獲得的資源保持不放。
（3） 不剝奪條件:進程已獲得的資源，在末使用完之前，不能強行剝奪。
（4） 循環等待條件:若干進程之間形成一種頭尾相接的循環等待資源關系。
這四個條件是死鎖的必要條件，只要系統發生死鎖，這些條件必然成立，而只要上述條件之
一不滿足，就不會發生死鎖。
死鎖的解除與預防：
理解了死鎖的原因，尤其是產生死鎖的四個必要條件，就可以最大可能地避免、預防和
解除死鎖。所以，在系統設計、進程調度等方面注意如何不讓這四個必要條件成立，如何確
定資源的合理分配演算法，避免進程永久占據系統資源。此外，也要防止進程在處於等待狀態
的情況下佔用資源。因此，對資源的分配要給予合理的規劃。