多執行緒環境下為了避免死鎖,一般提倡開放呼叫,開放呼叫可以避免死鎖,它的代價是失去原子性。但是在有些時候會顯得邏輯錯誤,例如:
例如
class a
if(changed)
}}boolean isstarted()
} void stop()
} if(changed)
} }
在單執行緒環境下這個**沒有任何問題。可是在多執行緒環境就會出現奇怪的現象。
原則上講, onstart 一定要走在onstop前面,可事實並非如此:
執行步驟如下:
執行緒1 start
執行緒2 stop
執行緒1 if(!misstarted)執行緒2 synchronized(this)
}執行緒2 onstop
執行緒1 onstart
現在onstop 走在了onstart前面。那麼問題來了,如何才能保證onstart 一定在onstop前面呢?
那麼問題又來了,stop 方法為什麼不允許在start之前呼叫呢?如果乙個類不可restart,那麼stop是可以在start之前的,否則是不可以在start之前的。
Android 多執行緒之Handler
前言 android的訊息傳遞機制是另外一種形式的 事件處理 這種機制主要是為了解決android應用中多執行緒的問題 在android中不允許activity新啟動的執行緒訪問該activity裡的ui元件,handler handler,它直接繼承自object,乙個handler允許傳送和處理...
Android 多執行緒之Looper
前言 handler messagequeue looper三者間的關係如圖 從上圖可以看出,handler傳送執行緒訊息到當前執行緒的messagequeue中,而looper用來管理messagequeue,它從messagequeue中取到訊息交給handler處理。looper 在activ...
Android多執行緒之IntentService
1.intentservice繼承自service public abstract class intentservice extends service override public void handlemessage message msg public intentservice stri...