findBug工具-Synchronization 相關(guān)問題的解決
1. findBug工具-Synchronization on Boolean（在Boolean類型的對象上使用了Synchronize關(guān)鍵字）
Bug原因:
在出現(xiàn)并發(fā)時(shí)，通過同步鎖使得只能由一個(gè)線程延遲加載一個(gè)或一組對象供后續(xù)使用（例如一個(gè)巨大的List或需要緩存的對象等等）。 然而，此前竟然從未意識(shí)到可能存在的嚴(yán)重問題。
其中，規(guī)則制定者一書的作者認(rèn)為錯(cuò)誤地在基本類型上使用synchronize關(guān)鍵字是導(dǎo)致并發(fā)問題的常見原因之一，可能導(dǎo)致死鎖或其他不可預(yù)測的結(jié)果，并將其抽象為不應(yīng)該在任何可能被重用的對象[包括可能在JVM內(nèi)部重用的對象]上使用.
即Boolean類型的對象不可用于synchronization同步鎖。其問題的實(shí)質(zhì)在于Boolean.TRUE和Boolean.FALSE這兩個(gè)常量在JVM中實(shí)際是java.lang.Boolean類的兩個(gè)靜態(tài)成員變量，因而可能在程序中被多處引用。例如，當(dāng)上例中的inited指向Boolean.FALSE時(shí)，如果有其他的同步代碼塊在無意中使用了相同的Boolean常量，那么就有可能導(dǎo)致死鎖。
2. findBug工具-Synchronizes on a boxed primitive object（在裝箱基本類型的對象上使用了Synchronize關(guān)鍵字）
上述代碼將int類型的count自動(dòng)裝箱為Interger包裝類型的對象Lock，然后使用synchronize關(guān)鍵字對包裝類型的Lock變量加鎖。可以預(yù)見，出于存儲(chǔ)和性能等等的考慮，在自動(dòng)裝箱時(shí)JVM內(nèi)部必然會(huì)重用具有相同值類型的包裝類，因而Lock指向的對象極有可能被重用，進(jìn)而在后續(xù)引發(fā)與Boolean類型變量存在的相同問題
3. findBug工具-Synchronizes on a interned String lock object（在內(nèi)部字符串對象上使用了Synchronize關(guān)鍵字）
根據(jù)Java API文檔，intern()方法實(shí)際是返回對象池中的對象，因而調(diào)用intern()方法后獲得到對象相當(dāng)于JVM中的一個(gè)全局變量。
所以，即便是像上述錯(cuò)誤代碼中使用private和final關(guān)鍵字修飾lock變量，lock變量指向的仍然是同一個(gè)可能被重用的字符串常量。這種情況所帶來的問題與之前提到的兩種問題類似。
4. findBug工具-Synchronizes on a String Literal（在字符串常量上使用了Synchronize關(guān)鍵字）
基于之前的解釋很容易理解第四種情況，即JVM中的字符串常量是全局重用的。
終極解決方案
- 使用字符串實(shí)例
與字符串常量不同，字符串實(shí)例的引用是唯一的，因而不存在字符串常量可能導(dǎo)致的問題。
- 使用private final類型的java.lang.Object
CERT規(guī)范中提到，這種解決方法是少數(shù)可以直接利用到j(luò)ava.lang.Object的情況。在此處之所以強(qiáng)調(diào)使用Raw Object，同時(shí)還在CERT規(guī)范的原文中多次提到《Use private final lock objects to synchronize classes that may interact with untrusted code》，是由于不使用Raw Object可能導(dǎo)致被exploit的問題，在此不再贅述。
