|
|
shyguy 原創(chuàng)
Java在語言層次上實(shí)現(xiàn)了對(duì)線程的支持。它提供了Thread/Runnable/ThreadGroup等一系列封裝的類和接口，讓程序員可以高效的開發(fā)Java多線程應(yīng)用。為了實(shí)現(xiàn)同步，Java提供了synchronize關(guān)鍵字以及object的wait()/notify()機(jī)制，可是在簡(jiǎn)單易用的背后，應(yīng)藏著更為復(fù)雜的玄機(jī)，很多問題就是由此而起。
一、Java內(nèi)存模型
在了解Java的同步秘密之前，先來看看JMM(Java Memory Model)。
Java被設(shè)計(jì)為跨平臺(tái)的語言，在內(nèi)存管理上，顯然也要有一個(gè)統(tǒng)一的模型。而且Java語言最大的特點(diǎn)就是廢除了指針，把程序員從痛苦中解脫出來，不用再考慮內(nèi)存使用和管理方面的問題。
可惜世事總不盡如人意，雖然JMM設(shè)計(jì)上方便了程序員，但是它增加了虛擬機(jī)的復(fù)雜程度，而且還導(dǎo)致某些編程技巧在Java語言中失效。
JMM主要是為了規(guī)定了線程和內(nèi)存之間的一些關(guān)系。對(duì)Java程序員來說只需負(fù)責(zé)用synchronized同步關(guān)鍵字，其它諸如與線程/內(nèi)存之間進(jìn)行數(shù)據(jù)交換/同步等繁瑣工作均由虛擬機(jī)負(fù)責(zé)完成。如圖1所示：根據(jù)JMM的設(shè)計(jì)，系統(tǒng)存在一個(gè)主內(nèi)存(Main Memory)，Java中所有變量都儲(chǔ)存在主存中，對(duì)于所有線程都是共享的。每條線程都有自己的工作內(nèi)存(Working Memory)，工作內(nèi)存中保存的是主存中某些變量的拷貝，線程對(duì)所有變量的操作都是在工作內(nèi)存中進(jìn)行，線程之間無法相互直接訪問，變量傳遞均需要通過主存完成。
圖1 Java內(nèi)存模型示例圖
線程若要對(duì)某變量進(jìn)行操作，必須經(jīng)過一系列步驟：首先從主存復(fù)制/刷新數(shù)據(jù)到工作內(nèi)存，然后執(zhí)行代碼，進(jìn)行引用/賦值操作，最后把變量?jī)?nèi)容寫回Main Memory。Java語言規(guī)范(JLS)中對(duì)線程和主存互操作定義了6個(gè)行為，分別為load，save，read，write，assign和use，這些操作行為具有原子性，且相互依賴，有明確的調(diào)用先后順序。具體的描述請(qǐng)參見JLS第17章。
我們?cè)谇懊娴恼鹿?jié)介紹了synchronized的作用，現(xiàn)在，從JMM的角度來重新審視synchronized關(guān)鍵字。
假設(shè)某條線程執(zhí)行一個(gè)synchronized代碼段，其間對(duì)某變量進(jìn)行操作，JVM會(huì)依次執(zhí)行如下動(dòng)作：
(1) 獲取同步對(duì)象monitor (lock)
(2) 從主存復(fù)制變量到當(dāng)前工作內(nèi)存 (read and load)
(3) 執(zhí)行代碼，改變共享變量值 (use and assign)
(4) 用工作內(nèi)存數(shù)據(jù)刷新主存相關(guān)內(nèi)容 (store and write)
(5) 釋放同步對(duì)象鎖 (unlock)
可見，synchronized的另外一個(gè)作用是保證主存內(nèi)容和線程的工作內(nèi)存中的數(shù)據(jù)的一致性。如果沒有使用synchronized關(guān)鍵字，JVM不保證第2步和第4步會(huì)嚴(yán)格按照上述次序立即執(zhí)行。因?yàn)楦鶕?jù)JLS中的規(guī)定，線程的工作內(nèi)存和主存之間的數(shù)據(jù)交換是松耦合的，什么時(shí)候需要刷新工作內(nèi)存或者更新主內(nèi)存內(nèi)容，可以由具體的虛擬機(jī)實(shí)現(xiàn)自行決定。如果多個(gè)線程同時(shí)執(zhí)行一段未經(jīng)synchronized保護(hù)的代碼段，很有可能某條線程已經(jīng)改動(dòng)了變量的值，但是其他線程卻無法看到這個(gè)改動(dòng)，依然在舊的變量值上進(jìn)行運(yùn)算，最終導(dǎo)致不可預(yù)料的運(yùn)算結(jié)果。
二、DCL失效
這一節(jié)我們要討論的是一個(gè)讓Java丟臉的話題：DCL失效。在開始討論之前，先介紹一下LazyLoad，這種技巧很常用，就是指一個(gè)類包含某個(gè)成員變量，在類初始化的時(shí)候并不立即為該變量初始化一個(gè)實(shí)例，而是等到真正要使用到該變量的時(shí)候才初始化之。
例如下面的代碼：
代碼1
-
- class Foo {
- private Resource res = null;
-
- public Resource getResource() {
- if (res == null)
- res = new Resource();
- return res;
- }
- }
由于LazyLoad可以有效的減少系統(tǒng)資源消耗，提高程序整體的性能，所以被廣泛的使用，連Java的缺省類加載器也采用這種方法來加載Java類。
在單線程環(huán)境下，一切都相安無事，但如果把上面的代碼放到多線程環(huán)境下運(yùn)行，那么就可能會(huì)出現(xiàn)問題。假設(shè)有2條線程，同時(shí)執(zhí)行到了if(res == null)，那么很有可能res被初始化2次，為了避免這樣的Race Condition，得用synchronized關(guān)鍵字把上面的方法同步起來。代碼如下：
代碼2
-
- Class Foo {
- Private Resource res = null;
- Public synchronized Resource getResource() {
- If (res == null)
- res = new Resource();
- return res;
- }
- }
現(xiàn)在Race Condition解決了，一切都很好。
N天過后，好學(xué)的你偶然看了一本Refactoring的魔書，深深為之打動(dòng)，準(zhǔn)備自己嘗試這重構(gòu)一些以前寫過的程序，于是找到了上面這段代碼。你已經(jīng)不再是以前的Java菜鳥，深知synchronized過的方法在速度上要比未同步的方法慢上100倍，同時(shí)你也發(fā)現(xiàn)，只有第一次調(diào)用該方法的時(shí)候才需要同步，而一旦res初始化完成，同步完全沒必要。所以你很快就把代碼重構(gòu)成了下面的樣子：
代碼3
-
- Class Foo {
- Private Resource res = null;
- Public Resource getResource() {
- If (res == null){
- synchronized(this){
- if(res == null){
- res = new Resource();
- }
- }
- }
- return res;
- }
- }
這種看起來很完美的優(yōu)化技巧就是Double-Checked Locking。但是很遺憾，根據(jù)Java的語言規(guī)范，上面的代碼是不可靠的。
造成DCL失效的原因之一是編譯器的優(yōu)化會(huì)調(diào)整代碼的次序。只要是在單個(gè)線程情況下執(zhí)行結(jié)果是正確的，就可以認(rèn)為編譯器這樣的“自作主張的調(diào)整代碼次序”的行為是合法的。JLS在某些方面的規(guī)定比較自由，就是為了讓JVM有更多余地進(jìn)行代碼優(yōu)化以提高執(zhí)行效率。而現(xiàn)在的CPU大多使用超流水線技術(shù)來加快代碼執(zhí)行速度，針對(duì)這樣的CPU，編譯器采取的代碼優(yōu)化的方法之一就是在調(diào)整某些代碼的次序，盡可能保證在程序執(zhí)行的時(shí)候不要讓CPU的指令流水線斷流，從而提高程序的執(zhí)行速度。正是這樣的代碼調(diào)整會(huì)導(dǎo)致DCL的失效。為了進(jìn)一步證明這個(gè)問題，引用一下《DCL Broken Declaration》文章中的例子：
設(shè)一行Java代碼：
-
- Objects[i].reference = new Object();
經(jīng)過Symantec JIT編譯器編譯過以后，最終會(huì)變成如下匯編碼在機(jī)器中執(zhí)行：
[pre]
0206106A mov eax,0F97E78h
0206106F call 01F6B210 ;為Object申請(qǐng)內(nèi)存空間
; 返回值放在eax中
02061074 mov dword ptr [ebp],eax ; EBP 中是objects[i].reference的地址
; 將返回的空間地址放入其中
; 此時(shí)Object尚未初始化
02061077 mov ecx,dword ptr [eax] ; dereference eax所指向的內(nèi)容
; 獲得新創(chuàng)建對(duì)象的起始地址
02061079 mov dword ptr [ecx],100h ; 下面4行是內(nèi)聯(lián)的構(gòu)造函數(shù)
0206107F mov dword ptr [ecx+4],200h
02061086 mov dword ptr [ecx+8],400h
0206108D mov dword ptr [ecx+0Ch],0F84030h
[/pre]
可見，Object構(gòu)造函數(shù)尚未調(diào)用，但是已經(jīng)能夠通過objects[i].reference獲得Object對(duì)象實(shí)例的引用。
如果把代碼放到多線程環(huán)境下運(yùn)行，某線程在執(zhí)行到該行代碼的時(shí)候JVM或者操作系統(tǒng)進(jìn)行了一次線程切換，其他線程顯然會(huì)發(fā)現(xiàn)msg對(duì)象已經(jīng)不為空，導(dǎo)致Lazy load的判斷語句if(objects[i].reference == null)不成立。線程認(rèn)為對(duì)象已經(jīng)建立成功，隨之可能會(huì)使用對(duì)象的成員變量或者調(diào)用該對(duì)象實(shí)例的方法，最終導(dǎo)致不可預(yù)測(cè)的錯(cuò)誤。
原因之二是在共享內(nèi)存的SMP機(jī)上，每個(gè)CPU有自己的Cache和寄存器，共享同一個(gè)系統(tǒng)內(nèi)存。所以CPU可能會(huì)動(dòng)態(tài)調(diào)整指令的執(zhí)行次序，以更好的進(jìn)行并行運(yùn)算并且把運(yùn)算結(jié)果與主內(nèi)存同步。這樣的代碼次序調(diào)整也可能導(dǎo)致DCL失效。回想一下前面對(duì)Java內(nèi)存模型的介紹，我們這里可以把Main Memory看作系統(tǒng)的物理內(nèi)存，把Thread Working Memory認(rèn)為是CPU內(nèi)部的Cache和寄存器，沒有synchronized的保護(hù)，Cache和寄存器的內(nèi)容就不會(huì)及時(shí)和主內(nèi)存的內(nèi)容同步，從而導(dǎo)致一條線程無法看到另一條線程對(duì)一些變量的改動(dòng)。
結(jié)合代碼3來舉例說明，假設(shè)Resource類的實(shí)現(xiàn)如下：
即Resource類有一個(gè)obj成員變量引用了Object的一個(gè)實(shí)例。假設(shè)2條線程在運(yùn)行，其狀態(tài)用如下簡(jiǎn)化圖表示：
圖2
現(xiàn)在Thread-1構(gòu)造了Resource實(shí)例，初始化過程中改動(dòng)了obj的一些內(nèi)容。退出同步代碼段后，因?yàn)椴扇×送綑C(jī)制，Thread-1所做的改動(dòng)都會(huì)反映到主存中。接下來Thread-2獲得了新的Resource實(shí)例變量res，由于沒有使用synchronized保護(hù)所以Thread-2不會(huì)進(jìn)行刷新工作內(nèi)存的操作。假如之前Thread-2的工作內(nèi)存中已經(jīng)有了obj實(shí)例的一份拷貝，那么Thread-2在對(duì)obj執(zhí)行use操作的時(shí)候就不會(huì)去執(zhí)行l(wèi)oad操作,這樣一來就無法看到Thread-1對(duì)obj的改變，這顯然會(huì)導(dǎo)致錯(cuò)誤的運(yùn)算結(jié)果。此外，Thread-1在退出同步代碼段的時(shí)刻對(duì)ref和obj執(zhí)行的寫入主存的操作次序也是不確定的，所以即使Thread-2對(duì)obj執(zhí)行了load操作，也有可能只讀到obj的初試狀態(tài)的數(shù)據(jù)。(注：這里的load/use均指JMM定義的操作)
有很多人不死心，試圖想出了很多精妙的辦法來解決這個(gè)問題，但最終都失敗了。事實(shí)上，無論是目前的JMM還是已經(jīng)作為JSR提交的JMM模型的增強(qiáng)，DCL都不能正常使用。在William Pugh的論文《Fixing the Java Memory Model》中詳細(xì)的探討了JMM的一些硬傷，更嘗試給出一個(gè)新的內(nèi)存模型，有興趣深入研究的讀者可以參見文后的參考資料。
如果你設(shè)計(jì)的對(duì)象在程序中只有一個(gè)實(shí)例，即singleton的，有一種可行的解決辦法來實(shí)現(xiàn)其LazyLoad：就是利用類加載器的LazyLoad特性。代碼如下：
-
- Class ResSingleton {
- public static Resource res = new Resource();
- }
這里ResSingleton只有一個(gè)靜態(tài)成員變量。當(dāng)?shù)谝淮问褂肦esSingleton.res的時(shí)候，JVM才會(huì)初始化一個(gè)Resource實(shí)例，并且JVM會(huì)保證初始化的結(jié)果及時(shí)寫入主存，能讓其他線程看到，這樣就成功的實(shí)現(xiàn)了LazyLoad。
除了這個(gè)辦法以外，還可以使用ThreadLocal來實(shí)現(xiàn)DCL的方法，但是由于ThreadLocal的實(shí)現(xiàn)效率比較低，所以這種解決辦法會(huì)有較大的性能損失，有興趣的讀者可以參考文后的參考資料。
最后要說明的是，對(duì)于DCL是否有效，個(gè)人認(rèn)為更多的是一種帶有學(xué)究氣的推斷和討論。而從純理論的角度來看，存取任何可能共享的變量（對(duì)象引用）都需要同步保護(hù)，否則都有可能出錯(cuò)，但是處處用synchronized又會(huì)增加死鎖的發(fā)生幾率，苦命的程序員怎么來解決這個(gè)矛盾呢？事實(shí)上，在很多Java開源項(xiàng)目（比如Ofbiz/Jive等）的代碼中都能找到使用DCL的證據(jù)，我在具體的實(shí)踐中也沒有碰到過因DCL而發(fā)生的程序異常。個(gè)人的偏好是：不妨先大膽使用DCL，等出現(xiàn)問題再用synchronized逐步排除之。也許有人偏于保守，認(rèn)為穩(wěn)定壓倒一切，那就不妨先用synchronized同步起來，我想這是一個(gè)見仁見智的問題，而且得針對(duì)具體的項(xiàng)目具體分析后才能決定。還有一個(gè)辦法就是寫一個(gè)測(cè)試案例來測(cè)試一下系統(tǒng)是否存在DCL現(xiàn)象，附帶的光盤中提供了這樣一個(gè)例子，感興趣的讀者可以自行編譯測(cè)試。不管結(jié)果怎樣，這樣的討論有助于我們更好的認(rèn)識(shí)JMM，養(yǎng)成用多線程的思路去分析問題的習(xí)慣，提高我們的程序設(shè)計(jì)能力。
三、Java線程同步增強(qiáng)包
相信你已經(jīng)了解了Java用于同步的3板斧：synchronized/wait/notify，它們的確簡(jiǎn)單而有效。但是在某些情況下，我們需要更加復(fù)雜的同步工具。有些簡(jiǎn)單的同步工具類，諸如ThreadBarrier，Semaphore，ReadWriteLock等，可以自己編程實(shí)現(xiàn)。現(xiàn)在要介紹的是牛人Doug Lea的Concurrent包。這個(gè)包專門為實(shí)現(xiàn)Java高級(jí)并行程序所開發(fā)，可以滿足我們絕大部分的要求。更令人興奮的是，這個(gè)包公開源代碼，可自由下載。且在JDK1.5中該包將作為SDK一部分提供給Java開發(fā)人員。
Concurrent Package提供了一系列基本的操作接口，包括sync，channel，executor,barrier,callable等。這里將對(duì)前三種接口及其部分派生類進(jìn)行簡(jiǎn)單的介紹。
sync接口：專門負(fù)責(zé)同步操作，用于替代Java提供的synchronized關(guān)鍵字，以實(shí)現(xiàn)更加靈活的代碼同步。其類關(guān)系圖如下：
圖3 Concurrent包Sync接口類關(guān)系圖
Semaphore：和前面介紹的代碼類似，可用于pool類實(shí)現(xiàn)資源管理限制。提供了acquire()方法允許在設(shè)定時(shí)間內(nèi)嘗試鎖定信號(hào)量，若超時(shí)則返回false。
Mutex：和Java的synchronized類似，與之不同的是，synchronized的同步段只能限制在一個(gè)方法內(nèi)，而Mutex對(duì)象可以作為參數(shù)在方法間傳遞，所以可以把同步代碼范圍擴(kuò)大到跨方法甚至跨對(duì)象。
NullSync：一個(gè)比較奇怪的東西，其方法的內(nèi)部實(shí)現(xiàn)都是空的，可能是作者認(rèn)為如果你在實(shí)際中發(fā)現(xiàn)某段代碼根本可以不用同步，但是又不想過多改動(dòng)這段代碼，那么就可以用NullSync來替代原來的Sync實(shí)例。此外，由于NullSync的方法都是synchronized，所以還是保留了“內(nèi)存壁壘”的特性。
ObservableSync：把sync和observer模式結(jié)合起來，當(dāng)sync的方法被調(diào)用時(shí)，把消息通知給訂閱者，可用于同步性能調(diào)試。
TimeoutSync：可以認(rèn)為是一個(gè)adaptor，其構(gòu)造函數(shù)如下：
public TimeoutSync(Sync sync, long timeout){…}
具體上鎖的代碼靠構(gòu)造函數(shù)傳入的sync實(shí)例來完成，其自身只負(fù)責(zé)監(jiān)測(cè)上鎖操作是否超時(shí)，可與SyncSet合用。
Channel接口：代表一種具備同步控制能力的容器，你可以從中存放/讀取對(duì)象。不同于JDK中的Collection接口，可以把Channel看作是連接對(duì)象構(gòu)造者(Producer)和對(duì)象使用者(Consumer)之間的一根管道。如圖所示：
圖4 Concurrent包Channel接口示意圖
通過和Sync接口配合，Channel提供了阻塞式的對(duì)象存取方法（put/take）以及可設(shè)置阻塞等待時(shí)間的offer/poll方法。實(shí)現(xiàn)Channel接口的類有LinkedQueue，BoundedLinkedQueue，BoundedBuffer，BoundedPriorityQueue，SynchronousChannel，Slot等。
圖5 Concurrent包Channel接口部分類關(guān)系圖
使用Channel我們可以很容易的編寫具備消息隊(duì)列功能的代碼，示例如下：
代碼4
-
- Package org.javaresearch.j2seimproved.thread;
-
- Import EDU.oswego.cs.dl.util.concurrent.*;
-
- public class TestChannel {
- final Channel msgQ = new LinkedQueue(); //log信息隊(duì)列
-
- public static void main(String[] args) {
- TestChannel tc = new TestChannel();
- For(int i = 0;i < 10;i ++){
- Try{
- tc.serve();
- Thread.sleep(1000);
- }catch(InterruptedException ie){
- }
- }
- }
-
- public void serve() throws InterruptedException {
- String status = doService();
- //把doService()返回狀態(tài)放入Channel，后臺(tái)logger線程自動(dòng)讀取之
- msgQ.put(status);
- }
-
- private String doService() {
- // Do service here
- return "service completed OK! ";
- }
-
- public TestChannel() { // start background thread
- Runnable logger = new Runnable() {
- public void run() {
- try {
- for (; ; )
- System.out.println("Logger: " + msgQ.take());
- }
- catch (InterruptedException ie) {}
- }
- };
- new Thread(logger).start();
- }
- }
Excutor/ThreadFactory接口: 把相關(guān)的線程創(chuàng)建/回收/維護(hù)/調(diào)度等工作封裝起來，而讓調(diào)用者只專心于具體任務(wù)的編碼工作（即實(shí)現(xiàn)Runnable接口），不必顯式創(chuàng)建Thread類實(shí)例就能異步執(zhí)行任務(wù)。
使用Executor還有一個(gè)好處，就是實(shí)現(xiàn)線程的“輕量級(jí)”使用。前面章節(jié)曾提到，即使我們實(shí)現(xiàn)了Runnable接口，要真正的創(chuàng)建線程，還是得通過new Thread()來完成，在這種情況下，Runnable對(duì)象(任務(wù))和Thread對(duì)象(線程)是1對(duì)1的關(guān)系。如果任務(wù)多而簡(jiǎn)單，完全可以給每條線程配備一個(gè)任務(wù)隊(duì)列，讓Runnable對(duì)象(任務(wù))和Executor對(duì)象變成n:1的關(guān)系。使用了Executor，我們可以把上面兩種線程策略都封裝到具體的Executor實(shí)現(xiàn)中，方便代碼的實(shí)現(xiàn)和維護(hù)。
具體的實(shí)現(xiàn)有: PooledExecutor，ThreadedExecutor，QueuedExecutor，F(xiàn)JTaskRunnerGroup等
類關(guān)系圖如下：
圖6 Concurrent包Executor/ThreadFactory接口部分類關(guān)系圖
下面給出一段代碼，使用PooledExecutor實(shí)現(xiàn)一個(gè)簡(jiǎn)單的多線程服務(wù)器
代碼5
-
- package org.javaresearch.j2seimproved.thread;
- import java.net.*;
- import EDU.oswego.cs.dl.util.concurrent.*;
-
- public class TestExecutor {
- public static void main(String[] args) {
- PooledExecutor pool =
- new PooledExecutor(new BoundedBuffer(10), 20);
- pool.createThreads(4);
- try {
- ServerSocket socket = new ServerSocket(9999);
- for (; ; ) {
- final Socket connection = socket.accept();
- pool.execute(new Runnable() {
- public void run() {
- new Handler().process(connection);
- }
- });
- }
- }
- catch (Exception e) {} // die
- }
- static class Handler {
- void process(Socket s){
- }
- }
- }
限于篇幅，這里只是蜻蜓點(diǎn)水式的介紹了Concurrent包，事實(shí)上還有相當(dāng)多有用的接口和類沒有提到，我們的配套光盤中附帶了Concurrent包和源代碼，感興趣的讀者可以自行分析。
| |
評(píng)論人：javamonkey 參與分: 61928 專家分: 1660 來自: 北京海淀區(qū)三里河
|
發(fā)表時(shí)間: 2003-9-3 上午9:19 |
| 好文章，好書，出書后我一定要去買一本看看，哈哈 | |
| 評(píng)論人：javaone 參與分: 42017 專家分: 870 |
發(fā)表時(shí)間: 2003-9-3 上午11:08 |
| 看來這本書值得一看！ | |
| 評(píng)論人：GLOBALone 參與分: 12 專家分: 0 |
發(fā)表時(shí)間: 2003-9-5 上午8:56 |
看不太懂啊大哥！
我知識(shí)java的初學(xué)者！
應(yīng)該看什么書啊？
請(qǐng)各位大哥指點(diǎn)！ | |
| 評(píng)論人：GLOBALone 參與分: 12 專家分: 0 |
發(fā)表時(shí)間: 2003-9-5 上午8:58 |
我只是java的初學(xué)者！看過thinking java 哪本書！ 好多地方
也是不太懂！我急啊！ | |
評(píng)論人：admin 參與分: 59502 專家分: 9080 來自: Java研究組織
|
發(fā)表時(shí)間: 2003-9-15 上午11:21 |
| 《J2SE進(jìn)階》是寫給學(xué)習(xí)、使用Java 半年～1年以上的朋友讀的書。對(duì)于入門，看《Java Tutorial》（中文版是：Java語言導(dǎo)學(xué)）是最好的教材。 | |
| 評(píng)論人：mosa 參與分: 15 專家分: 0 |
發(fā)表時(shí)間: 2003-10-29 下午5:02 |
文中所述第二個(gè)原因是JMM的固有問題，與DCL pattern無關(guān)。
Symantec JIT太老了，而且有很多問題，Oracle DB的安裝程序似乎還在用，但必須在命令行中關(guān)掉jit。文中列出的JIT'ed code顯然經(jīng)過了極其aggressive（甚至是錯(cuò)誤）的code scheduling，對(duì)照一下a[i] = new A()經(jīng)javac（或其它編譯器like jikes）產(chǎn)生的bytecode，GC分配返回的地址一般先存入stack，調(diào)用constructor，途徑local variable最后才aastore到數(shù)組a中，即使JIT可以優(yōu)化掉在stack和local variable中的存取，兩個(gè)calls，constructor和aastore（一般要進(jìn)行type check）是無法避免的，而call是可能具有side effect的（比如說throw exception），不能跨過call超前寫入內(nèi)存里。即使高明的JIT可以inline這些calls，對(duì)內(nèi)存的存取有alias問題，一般JIT不會(huì)做如此aggressive的code motion。目前典型的JIT，如Hotspot,IBM JRE, JRocket，一般都能讓DCL正確運(yùn)行在IA32和其它一些典型的architecture上。
現(xiàn)在JMM的mailing list最熱鬧的其實(shí)是一些研究hardware memory model的人，個(gè)人認(rèn)為Java程序員是完全不用害怕違反JMM而放棄使用一些典型的patterns。
作者很多對(duì)synchronized使用的建議是很有價(jià)值的，另外兩個(gè)重要的參考來源是：
Concurrent Programming in Java（Doug Lea）和Effective Java(Joshua Bloch)。 | |
評(píng)論人：shyguy 參與分: 20392 專家分: 560 來自: 西湖
|
發(fā)表時(shí)間: 2003-10-30 下午2:48 |
多謝mosa兄的精彩評(píng)述.
我曾經(jīng)自己用softice跟蹤過sun jvm,希望研究其如何在windows平臺(tái)上分配內(nèi)寸和初始化實(shí)例,跟蹤無數(shù)步而無所獲得,終于放棄. 我也曾設(shè)想過研究Jikes的src,但限于個(gè)人能力精力有限,最終未敢有所動(dòng)作.所以還是引用了別人的例子,就是那段過期的Symantec JIT編譯出來的代碼.
我本是一個(gè)實(shí)用主義者，同時(shí)為一個(gè)java程序員，對(duì)于JVM的設(shè)計(jì)與實(shí)現(xiàn)并不深入.但寫書畢竟與實(shí)用不同，而我深知網(wǎng)友口水的威力，所以花費(fèi)很多時(shí)間逡巡于國(guó)外的論壇和mailist，好好的學(xué)習(xí)了一些JVM深層次的東西,希望自己寫出來的內(nèi)容不至于貽笑大方.
在DCL和JMM問題的討論上，我希望讀者能夠了解到這更多的是一個(gè)理論上的爭(zhēng)論，對(duì)于這些問題如何解決，則已經(jīng)超出了java程序員的學(xué)習(xí)范圍。而我自己在實(shí)用過程中也是放手大膽的在使用DCL.希望書中蹩腳的行文沒有誤導(dǎo)廣大讀者。
同時(shí)，我想在本書的修訂版本中引入mosa兄的文字，作為補(bǔ)充參考，不知mosa兄意下如何。 | |
| 評(píng)論人：mosa 參與分: 15 專家分: 0 |
發(fā)表時(shí)間: 2003-10-31 下午2:12 |
| 不必客氣，shyguy兄，我認(rèn)為本文已經(jīng)是國(guó)內(nèi)有關(guān)Java/JVM研究最精辟的論述之一，雖然一直只看不說，也禁不住技癢狗尾續(xù)貂一次。關(guān)于JVM/CLI的問題以后可以多討論。 | |
評(píng)論人：Jagie 參與分: 73599 專家分: 3810 來自: 北京
|
發(fā)表時(shí)間: 2003-11-20 下午4:48 |
| 牛人啊，我還停留在使用api的階段。 | |
| 評(píng)論人：feng0000 參與分: 12 專家分: 0 |
發(fā)表時(shí)間: 2004-4-9 下午5:50 |
請(qǐng)大蝦們指點(diǎn)：
main()
{
thread = new Thread(this);
thread.start();
}
run()
{
synchronized (this)
{
f=true;
if(f==true) sleep(1000); 語句１
if(f==true) sleep(300); 語句２
語句3；
}
}
press()
{
f=false;
語句4；
thread = new Thread(this);
thread.start();
}
thread1:run 進(jìn)行同時(shí) press 使得f=false，此時(shí)語句１還沒sleep完事 又新起線程thread2，使得f=true;thread1 sleep(300);
我的本意想thread 1 在press 時(shí)退出run()不執(zhí)行語句２。
請(qǐng)問用 wait()/notify()怎么實(shí)現(xiàn)？我想在 語句3處加notify(),在語句4處加wait(),
但是不得這兩個(gè)函數(shù)的使用要領(lǐng)，monitor不清楚，能給出源碼么？謝謝。
| |
| 評(píng)論人：pig345 參與分: 12 專家分: 0 |
發(fā)表時(shí)間: 2004-7-28 上午10:06 |
不好意思，也來湊個(gè)熱鬧。
Class ResSingleton {
public static Resource res = new Resource();
}
這種，我以前的使用經(jīng)歷中好像失敗過。具體的環(huán)境忘了（好像是一個(gè)ejb項(xiàng)目）。 | | | 轉(zhuǎn)自：http://www.javaresearch.org/article/showarticle.jsp?column=544&thread=8832
|