java多線程鎖
㈠ java多線程『鎖』,是用什麼鎖的,有方法
多線程的同步鎖通過synchronized實現
有倆種方式 一種是在代碼塊加鎖
代碼塊加鎖時可以指定任意類的實例過的對象
即鎖在這個對象上(任何對象都有一個鎖)
使同一時間內只有一個線程可以訪問到代碼塊中
另外一種就是以synchronized關鍵字修飾方法
這時加鎖的對象就是類本身的實例 即this
以上 O(∩_∩)O
㈡ 怎麼處理JAVA多線程死鎖問題
有兩種實現方法,分別是繼承Thread類與實現Runnable
介面
用synchronized關鍵字修飾同步方法
反對使用stop(),是因為它不安全。它會解除由線程獲取的所有鎖定,而且如果對象處於一種不連貫狀態,那麼
其他線程能在那種狀態下檢查和修改它們。結果很難檢查出真正的問題所在。suspend()方法容易發生死鎖。調用
suspend()的時候,目標線程會停下來,但卻仍然持有在這之前獲得的鎖定。此時,其他任何線程都不能訪問鎖定
的資源,除非被"掛起"的線程恢復運行。對任何線程來說,如果它們想恢復目標線程,同時又試圖使用任何一個
鎖定的資源,就會造成死鎖。所以不應該使用suspend(),而應在自己的Thread類中置入一個標志,指出線程應該
活動還是掛起。若標志指出線程應該掛起,便用wait()命其進入等待狀態。若標志指出線程應當恢復,則用一個
notify()重新啟動線程。
㈢ java 程序中怎麼保證多線程的運行安全
2.1.讀一致性
Java 中針對上述「讀不安全」的問題提供了關鍵字 volatile 來解決問題,被 volatile 修飾的成員變數,在內容發生更改的時候,會通知所有線程去主內存更新最新的值,這樣就解決了讀不安全的問題,實現了讀一致性。
但是,讀一致性是無法解決寫一致性的,雖然能夠使得每個線程都能及時獲取到最新的值,但是1.1中的寫一致性問題還是會存在。
既然如此,Java 為啥還要提供 volatile 關鍵字呢?這並非多餘的存在,在某些場景下只需要讀一致性的話,這個關鍵字就能夠滿足需求而且性能相對還不錯,因為其他的能夠保證「讀寫」都一直的辦法,多多少少存在一些犧牲。
2.2.寫一致性
Java 提供了三種方式來保證讀寫一致性,分別是互斥鎖、自旋鎖、線程隔離。
2.2.1.互斥鎖
互斥鎖只是一個鎖概念,在其他場景也叫做獨占鎖、悲觀鎖等,其實就是一個意思。它是指線程之間是互斥的,某一個線程獲取了某個資源的鎖,那麼其他線程就只能睡眠等待。
在 Java 中互斥鎖的實現一般叫做同步線程鎖,關鍵字 synchronized,它鎖住的范圍是它修飾的作用域,鎖住的對象是:當前對象(對象鎖)或類的全部對象(類鎖)——鎖釋放前,其他線程必將阻塞,保證鎖住范圍內的操作是原子性的,而且讀取的數據不存在一致性問題。
對象鎖:當它修飾方法、代碼塊時,將會鎖住當前對象
類鎖:修飾類、靜態方法時,則是鎖住類的所有對象
注意:鎖住的永遠是對象,鎖住的范圍永遠是 synchronized 關鍵字後面的花括弧劃定的代碼域。
2.2.2.自旋鎖
自旋鎖也只是一個鎖概念,在其他場景也叫做樂觀鎖等。
自旋鎖本質上是不加鎖,而是通過對比舊數據來決定是否更新:
㈣ JAVA程序設計,多線程且避免死鎖
JAVA中幾種常見死鎖及對策:解決死鎖沒有簡單的方法,這是因為線程產生死鎖都各有各的原因,而且往往具有很高的負載。大多數軟體測試產生不了足夠多的負載,所以不可能暴露所有的線程錯誤。在這里中,下面將討論開發過程常見的4類典型的死鎖和解決對策。(1)資料庫死鎖在資料庫中,如果一個連接佔用了另一個連接所需的資料庫鎖,則它可以阻塞另一個連接。如果兩個或兩個以上的連接相互阻塞,則它們都不能繼續執行,這種情況稱為資料庫死鎖。資料庫死鎖問題不易處理,通常數據行進行更新時,需要鎖定該數據行,執行更新,然後在提交或回滾封閉事務時釋放鎖。由於資料庫平台、配置的隔離級以及查詢提示的不同,獲取的鎖可能是細粒度或粗粒度的,它會阻塞(或不阻塞)其他對同一數據行、表或資料庫的查詢。基於資料庫模式,讀寫操作會要求遍歷或更新多個索引、驗證約束、執行觸發器等。每個要求都會引入鎖。此外,其他應用程序還可能正在訪問同一資料庫模式中的某些對象,並獲取不同應用程序所具有的鎖。所有這些因素綜合在一起,資料庫死鎖幾乎不可能被消除了。值得慶幸的是,資料庫死鎖通常是可恢復的:當資料庫發現死鎖時,它會強制銷毀一個連接(通常是使用最少的連接),並回滾其事務。這將釋放所有與已經結束的事務相關聯的鎖,至少允許其他連接中有一個可以獲取它們正在被阻塞的鎖。由於資料庫具有這種典型的死鎖處理行為,所以當出現資料庫死鎖問題時,資料庫常常只能重試整個事務。當資料庫連接被銷毀時,會拋出可被應用程序捕獲的異常,並標識為資料庫死鎖。如果允許死鎖異常傳播到初始化該事務的代碼層之外,則該代碼層可以啟動一個新事務並重做先前所有工作。當出現問題就重試,由於資料庫可以自由地獲取鎖,所以幾乎不可能保證兩個或兩個以上的線程不發生資料庫死鎖。此方法至少能保證在出現某些資料庫死鎖情況時,應用程序能正常運行。(2)資源池耗盡死鎖客戶端的增加導致資源池耗盡死鎖是由於負載而造成的,即資源池太小,而每個線程需要的資源超過了池中的可用資源。假設連接池最多有10個連接,同時有10個對外部並發調用。這些線程中每一個都需要一個資料庫連接用來清空池。現在,每個線程都執行嵌套的調用。則所有線程都不能繼續,但又都不放棄自己的第一個資料庫連接。這樣,10個線程都將被死鎖。研究此類死鎖,會發現線程存儲中有大量等待獲取資源的線程,以及同等數量的空閑且未阻塞的活動資料庫連接。當應用程序死鎖時,如果可以在運行時檢測連接池,就能確認連接池實際上已空。修復此類死鎖的方法包括:增加連接池的大小或者重構代碼,以便單個線程不需要同時使用很多資料庫連接。或者可以設置內部調用使用不同的連接池,即使外部調用的連接池為空,內部調用也能使用自己的連接池繼續。(3)單線程、多沖突資料庫連接死鎖對同一線程執行嵌套的調用有時出現死鎖,此情形即使在非高負載系統中通常也會發生。當第一個(外部)連接已獲取第二個(內部)連接所需要的資料庫鎖,則第二個連接將永久阻塞第一個連接,並等待第一個連接被提交或回滾,這就出現了死鎖情形。因為資料庫沒有注意到兩個連接之間的關系,所以資料庫不會將此情形檢測為死鎖。這樣即使不存在並發,此代碼也將導致死鎖。此情形有多種具體的變種,可以涉及多個線程和兩個以上的資料庫連接。(4)Java虛擬機鎖與資料庫鎖沖突這種情形發生在資料庫鎖與Java虛擬機鎖並存的時候。在這種情況下,一個線程佔有一個資料庫鎖並嘗試獲取Java虛擬機鎖。同時,另一個線程佔有Java虛擬機鎖並嘗試獲取資料庫鎖。此時,資料庫發現一個連接阻塞了另一個連接,但由於無法阻止連接繼續,所以不會檢測到死鎖。Java虛擬機發現同步的鎖中有一個線程,並有另一個嘗試進入的線程,所以即使Java虛擬機能檢測到死鎖並對它們進行處理,它還是不會檢測到這種情況。總而言之,JAVA應用程序中的死鎖是一個大問題——它能導致整個應用程序慢慢終止,還很難被分離和修復,尤其是當開發人員不熟悉如何分析死鎖環境的時候。五.死鎖的經驗法則筆者在開發中總結以下死鎖問題的經驗。(1)對大多數的Java程序員來說最簡單的防止死鎖的方法是對競爭的資源引入序號,如果一個線程需要幾個資源,那麼它必須先得到小序號的資源,再申請大序號的資源。可以在Java代碼中增加同步關鍵字的使用,這樣可以減少死鎖,但這樣做也會影響性能。如果負載過重,資料庫內部也有可能發生死鎖。(2)了解資料庫鎖的發生行為。假定任何資料庫訪問都有可能陷入資料庫死鎖狀況,但是都能正確進行重試。例如了解如何從應用伺服器獲取完整的線程轉儲以及從資料庫獲取資料庫連接列表(包括互相阻塞的連接),知道每個資料庫連接與哪個Java線程相關聯。了解Java線程和資料庫連接之間映射的最簡單方法是向連接池訪問模式添加日誌記錄功能。(3)當進行嵌套的調用時,了解哪些調用使用了與其它調用同樣的資料庫連接。即使嵌套調用運行在同一個全局事務中,它仍將使用不同的資料庫連接,而不會導致嵌套死鎖。(4)確保在峰值並發時有足夠大的資源池。(5)避免執行資料庫調用或在佔有Java虛擬機鎖時,執行其他與Java虛擬機無關的操作。最重要的是,多線程設計雖然是困難的,但在開始編程之前詳細設計系統能夠幫助你避免難以發現死鎖的問題。死鎖在語言層面上不能解決,就需要一個良好設計來避免死鎖。