建站
咨詢
售后
建站咨詢
新聞中心
不提倡使用的方法是為支持向后兼容性而保留的那些方法，它們在以后的版本中可能出現(xiàn)，也可能不出現(xiàn)。Java 多線程支持在版本 1.1 和版本 1.2 中做了重大修訂，stop()、suspend() 和 resume() 函數(shù)已不提倡使用。這些函數(shù)在 JVM 中可能引入微妙的錯誤。雖然函數(shù)名可能聽起來很誘人，但請抵制誘惑不要使用它們。
成都一家集口碑和實力的網(wǎng)站建設(shè)服務(wù)商，擁有專業(yè)的企業(yè)建站團(tuán)隊和靠譜的建站技術(shù)，10多年企業(yè)及個人網(wǎng)站建設(shè)經(jīng)驗 ,為成都1000+客戶提供網(wǎng)頁設(shè)計制作,網(wǎng)站開發(fā),企業(yè)網(wǎng)站制作建設(shè)等服務(wù),包括成都營銷型網(wǎng)站建設(shè)，高端網(wǎng)站設(shè)計，同時也為不同行業(yè)的客戶提供網(wǎng)站制作、成都網(wǎng)站設(shè)計的服務(wù),包括成都電商型網(wǎng)站制作建設(shè),裝修行業(yè)網(wǎng)站制作建設(shè)，傳統(tǒng)機(jī)械行業(yè)網(wǎng)站建設(shè),傳統(tǒng)農(nóng)業(yè)行業(yè)網(wǎng)站制作建設(shè)。在成都做網(wǎng)站,選網(wǎng)站制作建設(shè)服務(wù)商就選創(chuàng)新互聯(lián)建站。
調(diào)試線程化的程序
在Java線程化的程序中，可能發(fā)生的某些常見而討厭的情況是死鎖、活鎖、內(nèi)存損壞和資源耗盡。
死鎖
死鎖可能是Java多線程程序最常見的問題。當(dāng)一個線程需要一個資源而另一個線程持有該資源的鎖時，就會發(fā)生死鎖。這種情況通常很難檢測。但是，解決方案卻相當(dāng)好：在所有的線程中按相同的次序獲取所有資源鎖。例如，如果有四個資源 —A、B、C 和 D — 并且一個線程可能要獲取四個資源中任何一個資源的鎖，則請確保在獲取對 B 的鎖之前首先獲取對 A 的鎖，依此類推。如果“線程 1”希望獲取對 B 和 C 的鎖，而“線程 2”獲取了 A、C 和 D 的鎖，則這一技術(shù)可能導(dǎo)致阻塞，但它永遠(yuǎn)不會在這四個鎖上造成死鎖。
活鎖
當(dāng)一個線程忙于接受新任務(wù)以致它永遠(yuǎn)沒有機(jī)會完成任何任務(wù)時，就會發(fā)生活鎖。這個線程最終將超出緩沖區(qū)并導(dǎo)致程序崩潰。試想一個秘書需要錄入一封信，但她一直在忙于接電話，所以這封信永遠(yuǎn)不會被錄入。
內(nèi)存損壞
如果明智地使用 synchronized 關(guān)鍵字，則完全可以避免內(nèi)存錯誤這種氣死人的問題。
資源耗盡
某些系統(tǒng)資源是有限的，如文件描述符。多線程程序可能耗盡資源，因為每個線程都可能希望有一個這樣的資源。如果線程數(shù)相當(dāng)大，或者某個資源的侯選線程數(shù)遠(yuǎn)遠(yuǎn)超過了可用的資源數(shù)，則最好使用 資源池。一個最好的示例是數(shù)據(jù)庫連接池。只要線程需要使用一個數(shù)據(jù)庫連接，它就從池中取出一個，使用以后再將它返回池中。資源池也稱為 資源庫。
調(diào)試大量的線程
在Java多線程程序中，有時一個程序因為有大量的線程在運行而極難調(diào)試。在這種情況下，下面的這個類可能會派上用場：
以下是引用片段：
public class Probe extends Thread {
public Probe() {}
public void run() {
while(true) {
Thread[] x = new Thread[100];
Thread.enumerate(x);
for(int i=0; i<100; i++) {
Thread t = x[i];
if(t == null)
break;
else
System.out.println(t.getName() + "\t" + t.getPriority()
+ "\t" + t.isAlive() + "\t" + t.isDaemon());
}
}
}
}
【編輯推薦】
- Java會幸存 但Sun其余產(chǎn)品命運難料
- 如何理解JavaFX的應(yīng)運而生
- 精選的25個Java試題分享
- Java 理論與實踐: 用弱引用堵住內(nèi)存泄漏
新聞標(biāo)題：實戰(zhàn)Java多線程編程之不提倡的方法
文章鏈接：http://www.5511xx.com/article/dhjcjpj.html
