轉(zhuǎn)載請(qǐng)注明出處：http://blog.csdn.net/w525721508/article/details/77198233
synchronized函數(shù)和synchronized代碼塊的區(qū)別
- 首先synchronized函數(shù)和synchronized代碼快的作用范圍有區(qū)別，synchronized函數(shù)一般鎖定的是當(dāng)前類對(duì)象，synchronized代碼塊鎖定作用域可以選擇是本對(duì)象，也可以是字符串等等.
- 當(dāng)前類對(duì)象鎖沒(méi)有釋放的時(shí)候跛梗，本類的所有synchronized(this)同步代碼塊都阻塞款熬。如果有并發(fā)請(qǐng)求synchronized函數(shù)羊瘩，同一時(shí)間只能有一個(gè)請(qǐng)求執(zhí)行 .
- 但是當(dāng)前類對(duì)象鎖沒(méi)有釋放的時(shí)候岛心，其他請(qǐng)求可以訪問(wèn)本類中不帶synchronized(this)的代碼塊题画，也可以訪問(wèn)非同一把鎖的代碼塊例如synchronized(Str)等.
- 由于作用范圍有區(qū)別乡范，一般作用范圍越小執(zhí)行效率越高配名，平時(shí)開(kāi)發(fā)中一般選擇作用范圍較小的synchronized.
如何判斷一個(gè)對(duì)象是可以被回收的
- 之前java虛擬機(jī)使用引用計(jì)數(shù)器的算法，當(dāng)引用計(jì)數(shù)器為0時(shí)代表該對(duì)象沒(méi)有引用了然后被清理晋辆。但是這個(gè)方式很難解決循環(huán)引用問(wèn)題渠脉，所以目前停止使用了。
- 目前用到的是可達(dá)性分析算法來(lái)確定一個(gè)對(duì)象是不是可以被回收瓶佳。
- 原理是：通過(guò)一個(gè)叫GC Roots的對(duì)象當(dāng)作根對(duì)象芋膘，然后開(kāi)始向下搜索，搜索的路徑叫做引用鏈霸饲，當(dāng)對(duì)象到GC Roots沒(méi)有任何引用鏈相連的時(shí)候为朋，則證明此對(duì)象是不可用的.
- 不可用對(duì)象并不是馬上就執(zhí)行回收方法，執(zhí)行清理方法之前至少要經(jīng)歷兩次標(biāo)記過(guò)程.
- ①如果對(duì)象在進(jìn)行可達(dá)性分析后發(fā)現(xiàn)沒(méi)有與GC Roots相連接的引用鏈,那它將會(huì)被第一次標(biāo)記并且進(jìn)行一次篩選,篩選的條件是此對(duì)象是否有必要執(zhí)行finalize()方法厚脉。當(dāng)對(duì)象沒(méi)有覆蓋finalize()方法,或者finalize()方法已經(jīng)被虛擬機(jī)調(diào)用過(guò),虛擬機(jī)將這兩種情況都視為“沒(méi)有必要執(zhí)行”习寸。(即意味著直接回收).
- ②如果這個(gè)對(duì)象被判定為有必要執(zhí)行finalize()方法,那么這個(gè)對(duì)象將會(huì)放置在一個(gè)叫做F-Queue的隊(duì)列之中,并在稍后由一個(gè)由虛擬機(jī)自動(dòng)建立的、低優(yōu)先級(jí)的Finalizer線程去執(zhí)行它傻工。這里所謂的“執(zhí)行”是指虛擬機(jī)會(huì)觸發(fā)這個(gè)方法,但并不承諾會(huì)等待它運(yùn)行結(jié)束,這樣做的原因是,如果一個(gè)對(duì)象在finalize()方法中執(zhí)行緩慢,或者發(fā)生了死循環(huán)(更極端的情況),將很可能會(huì)導(dǎo)致F-Queue隊(duì)列中其他對(duì)象永久處于等待,甚至導(dǎo)致整個(gè)內(nèi)存回收系統(tǒng)崩潰.
- finalize()方法是對(duì)象回收前的最后一次機(jī)會(huì),稍后GC將對(duì)F-Queue中的對(duì)象進(jìn)行第二次小規(guī)模的標(biāo)記,如果對(duì)象要在finalize()中不被回收霞溪，只要重新與引用鏈上的任何一個(gè)對(duì)象建立關(guān)聯(lián)即可,譬如把自己(this關(guān)鍵字)賦值給某個(gè)類變量或者對(duì)象的成員變量,那在第二次標(biāo)記時(shí)它將被移除出“即將回收”的集合;如果對(duì)象這時(shí)候還沒(méi)有逃脫,那基本上它就真的被回收了。
- 任何一個(gè)對(duì)象的finalize()方法都只會(huì)被系統(tǒng)自動(dòng)調(diào)用一次,如果對(duì)象面臨下一次回收,它的finalize()方法不會(huì)被再次執(zhí)行,因此第二段代碼的自救行動(dòng)失敗了中捆。因?yàn)閒inalize()方法已經(jīng)被虛擬機(jī)調(diào)用過(guò),虛擬機(jī)都視為“沒(méi)有必要執(zhí)行”鸯匹。(即意味著直接回收).
寫(xiě)一個(gè)函數(shù)，輸入一個(gè)數(shù)如38泄伪，拆分 3 + 8 = 11殴蓬，1 + 1 = 2，最后2無(wú)法拆分就返回
public int getNum(int num) {
while (num >= 10) {
num = num / 10 + num % 10;
}
return num;
}
多個(gè)進(jìn)程同時(shí)調(diào)用一個(gè)ContentProvider的query獲取數(shù)據(jù)蟋滴，ContentPrvoider是如何反應(yīng)的呢染厅？
-
分析：
我們知道Activity這樣的組件痘绎，它生命周期的回調(diào)函數(shù)是在UI線程中執(zhí)行的，ContentProvider的onCreate()方法也是在UI線程中運(yùn)行的肖粮，回答這個(gè)問(wèn)題前简逮，我們首先要搞清楚ContentProvider的Query()，insert()尿赚，delete()，updata()這幾個(gè)方法是否也是在UI線程中運(yùn)行蕉堰。
-
發(fā)現(xiàn)問(wèn)題：
如果以上幾個(gè)方法是在UI線程中運(yùn)行的凌净，那么多個(gè)線程并發(fā)去調(diào)用就很有可能出現(xiàn)ANR；如果不是在UI線程運(yùn)行的屋讶，那它是在一個(gè)工作線程中運(yùn)行的還是在多個(gè)線程中運(yùn)行的呢冰寻？即ContentProvider是否支持并發(fā)操作呢？
-
分析問(wèn)題：
ContentResolver與ContentProvider類隱藏了實(shí)現(xiàn)細(xì)節(jié)皿渗，但是ContentProvider所提供的Query()斩芭，insert()，delete()乐疆，updata()這幾個(gè)方法都是在ContentProvider進(jìn)行的線程池中運(yùn)行的划乖，而不是在進(jìn)程的主線程中運(yùn)行，以為這些方法有可能被多個(gè)地方調(diào)用挤土，所以它們是線程安全的琴庵。
ContentProvider實(shí)現(xiàn)進(jìn)程通信是依賴于Binder機(jī)制的，所以以上問(wèn)題會(huì)回歸到Binder線程處理問(wèn)題仰美，并不是每一個(gè)ContentProvider都會(huì)有一個(gè)線程池迷殿，而是一個(gè)進(jìn)程共用一個(gè)線程池，共用的線程池就是Binder線程池咖杂。
-
標(biāo)準(zhǔn)答案：
一個(gè)content provider可以接受來(lái)自另外一個(gè)進(jìn)程的數(shù)據(jù)請(qǐng)求庆寺。盡管ContentResolver與ContentProvider類隱藏了實(shí)現(xiàn)細(xì)節(jié)，但是ContentProvider所提供的query()诉字，insert()懦尝，delete()，update()都是在ContentProvider進(jìn)程的線程池中被調(diào)用執(zhí)行的奏窑，而不是進(jìn)程的主線程中导披。這個(gè)線程池是有Binder創(chuàng)建和維護(hù)的，其實(shí)使用的就是每個(gè)應(yīng)用進(jìn)程中的Binder線程池埃唯。
Android設(shè)計(jì)ContentProvider的目的是什么撩匕？
- 隱藏?cái)?shù)據(jù)的實(shí)現(xiàn)方式，對(duì)外提供統(tǒng)一的數(shù)據(jù)訪問(wèn)接口墨叛；
- 更好的數(shù)據(jù)訪問(wèn)權(quán)限管理止毕。ContentProvider可以對(duì)開(kāi)發(fā)的數(shù)據(jù)進(jìn)行權(quán)限設(shè)置模蜡，不同的URI可以對(duì)應(yīng)不同的權(quán)限，只有符合權(quán)限要求的組件才能訪問(wèn)到ContentProvider的具體操作扁凛。
- ContentProvider封裝了跨進(jìn)程共享的邏輯忍疾，我們只需要Uri即可訪問(wèn)數(shù)據(jù)。由系統(tǒng)來(lái)管理ContentProvider的創(chuàng)建谨朝、生命周期及訪問(wèn)的線程分配卤妒，簡(jiǎn)化我們?cè)趹?yīng)用間共享數(shù)據(jù)（進(jìn)程間通信）的方式。我們只管通過(guò)ContentResolver訪問(wèn)ContentProvider所提示的數(shù)據(jù)接口字币，而不需要擔(dān)心它所在進(jìn)程是啟動(dòng)還是未啟動(dòng)则披。
運(yùn)行在主線程的ContentProvider為什么不會(huì)影響主線程的UI操作?
- ContentProvider的onCreate()是運(yùn)行在UI線程的，而query()洗出，insert()士复，delete()，update()是運(yùn)行在線程池中的工作線程的翩活，所以調(diào)用這向個(gè)方法并不會(huì)阻塞ContentProvider所在進(jìn)程的主線程阱洪，但可能會(huì)阻塞調(diào)用者所在的進(jìn)程的UI線程！
- 所以菠镇，調(diào)用ContentProvider的操作仍然要放在子線程中去做冗荸。雖然直接的CRUD的操作是在工作線程的，但系統(tǒng)會(huì)讓你的調(diào)用線程等待這個(gè)異步的操作完成利耍，你才可以繼續(xù)線程之前的工作俏竞。
