多核時(shí)代考驗(yàn)Java代碼編寫習(xí)慣
譯文【51CTO精選譯文】我承認(rèn)，這個(gè)標(biāo)題是有點(diǎn)夸大其辭了。顯然正確的Java還是有的，甚至有不少，但是我感覺(jué)這相對(duì)于Java代碼的總量來(lái)說(shuō)可能只是微不足道的一小部分。為什么我會(huì)有這么極端的一個(gè)說(shuō)法呢？
這又回到了Java內(nèi)存模型問(wèn)題上，以及對(duì)于在代碼運(yùn)行時(shí)“計(jì)算機(jī)”中發(fā)生了些什么的不符合人們直覺(jué)思維的。為了避免有人說(shuō)我對(duì)Java有偏見(jiàn)，我得先聲明，我非常清楚Java是第一種試圖提供可靠，可用，跨平臺(tái)的多線程編程環(huán)境的語(yǔ)言。這是很難做到的。在初試嘗試時(shí)一些細(xì)節(jié)問(wèn)題上出現(xiàn)了重大錯(cuò)誤也應(yīng)該不會(huì)有人覺(jué)得奇怪。那此問(wèn)題到JSR-133就被解決了，從Java 5開(kāi)始就被廣泛部署開(kāi)來(lái)。
但是，即使用的較新的Java環(huán)境，帶有更寬松、可預(yù)見(jiàn)性更強(qiáng)的的內(nèi)存模型，還是會(huì)有很多錯(cuò)誤發(fā)生，而我們也粗心大意根本沒(méi)有注意這些問(wèn)題。這是怎么回事呢？必讀書目《Java并發(fā)編程實(shí)踐》（Java Concurrency in Practice，51CTO讀書頻道有這本書的試讀。后面我還會(huì)提到這本書）的作者Brian Goetz說(shuō)得好：
“……由于常用的處理器（Intel和Sparc）都提供比JVM所需更強(qiáng)的存儲(chǔ)能力，即使許多開(kāi)發(fā)人員經(jīng)常錯(cuò)誤地使用同步和volatile，但是因?yàn)椴渴鸬奶幚砥骷軜?gòu)能提供很強(qiáng)的存儲(chǔ)能力，所以得以僥幸避免出錯(cuò)。”
這面這段引用是他這個(gè)月所作的講話的一個(gè)摘要。我真希望我能去聽(tīng)講。隨著越來(lái)越多的電腦擁有了多個(gè)多核處理器，我們以前依賴的內(nèi)存行為開(kāi)始消失了，我們這些Java開(kāi)發(fā)人員也從以前那種僥幸的、錯(cuò)誤的方式中醒悟過(guò)來(lái)。
51CTO編輯推薦：哪種語(yǔ)言將統(tǒng)治多核時(shí)代 再看函數(shù)式語(yǔ)言特性
這一切的失敗仿佛早就注定。我們學(xué)習(xí)Java的許多方式，不管是通過(guò)示例程序，課堂教學(xué)或是書籍，都導(dǎo)致了這些錯(cuò)誤。所以我們有了根深蒂固的錯(cuò)誤而且危險(xiǎn)的思維習(xí)慣，并且還導(dǎo)致我們以一種錯(cuò)誤的方式來(lái)思考程序……這也導(dǎo)致了在部署過(guò)程中發(fā)生一些不起眼的錯(cuò)誤，這些錯(cuò)誤日后極難被找出和修復(fù)。
難道只有多線程程序中才有這個(gè)問(wèn)題？還有，專家所寫的代碼中難道不會(huì)少一點(diǎn)這些問(wèn)題嗎？不是這樣的。想想使用Swing圖形界面工具包開(kāi)發(fā)的程序。或者，更常見(jiàn)的，運(yùn)行在Servlet容器中的一個(gè)服務(wù)端程序。在這種兩種情況下，你都被迫進(jìn)入了多線程環(huán)境。
我想我們大多數(shù)人都對(duì)如何處理競(jìng)爭(zhēng)條件和死鎖以及如何用同步解決問(wèn)題有好的辦法，特別是當(dāng)涉及到多個(gè)變量時(shí)。這些是很難學(xué)會(huì)的，但是長(zhǎng)期以來(lái)好的例子，還有大環(huán)境的影響，讓我們?cè)诶斫夂瓦\(yùn)用多線程編程上走上正軌。
即便如此，像雙檢測(cè)鎖定這樣一些爛方法的存在說(shuō)明我們的理解還有問(wèn)題。而我們的東西在什么地方散架也只是一個(gè)明不明顯的問(wèn)題。如果不合適地使用同步或volatile來(lái)聲明變量，即使是很穩(wěn)定不變的的值也有可能在其它線程中完全看不到。我們所理解的一個(gè)像共享池一樣的主存實(shí)在是過(guò)于簡(jiǎn)化了，這導(dǎo)致我們對(duì)于代碼將有哪些行為和哪些是安全的會(huì)作出錯(cuò)誤的判斷。
最近我們的一個(gè)產(chǎn)品在用戶多核處理器上的站點(diǎn)出現(xiàn)了問(wèn)題，這讓我對(duì)這一點(diǎn)更加刻骨銘心。這個(gè)問(wèn)題我們自己沒(méi)法重現(xiàn)，在測(cè)試中也沒(méi)出現(xiàn)過(guò)，但是通過(guò)禁用一個(gè)處理器，這個(gè)問(wèn)題就可以解決。此后不久，我的一位同事根據(jù)他在《Java并發(fā)編程實(shí)踐》中所讀到的一些內(nèi)容為當(dāng)?shù)氐腏ava用戶組作了一次演講，這讓我想起來(lái)我一直想讀這本書，我也該抽時(shí)間讀讀這本書了。
我也這樣做了。這還真是讓我大開(kāi)眼界。它明確了一些我以前在JavaOne以及網(wǎng)上聽(tīng)說(shuō)過(guò)的，卻從來(lái)沒(méi)有融會(huì)貫通的一些問(wèn)題。它讓我更明白了Java代碼的真正意義，以及如何寫安全的Java代碼。我們團(tuán)隊(duì)一直一起閱讀這本書，有好幾個(gè)星期都在午餐后討論這本書，它讓我們能修正我們的Java代碼，使其在多處理器上也正常運(yùn)行。多處理器曾經(jīng)很昂貴并且不穩(wěn)定，但現(xiàn)在正成為主流。所以這并不能說(shuō)是為時(shí)尚早——我們還希望能在之前就深入了解這些呢。將所學(xué)的這些靈活運(yùn)用，讓我們建立起寫無(wú)誤代碼的信心還需要一些時(shí)間，但至少我們走上了正軌。
每個(gè)寫Java的人都應(yīng)該讀讀這本書，為了他們自己，還有他們的用戶。Brian Goetz為IBM developerWorks所寫的兩篇文章（一、二）可以作為我這里所提到的這些問(wèn)題的一個(gè)總結(jié)，但是那并不能代替擁有大量分析、建議還有范例的《Java并發(fā)編程實(shí)踐》。
不過(guò)，即使我們?cè)诎l(fā)現(xiàn)這些問(wèn)題上變得很厲害了，這問(wèn)題也還是不那么容易解決。這也促使我思考并認(rèn)真看看Scala，它是一門較新的語(yǔ)言，可以在JVM中和其它的語(yǔ)言一起運(yùn)行，并通過(guò)更可靠和可信的函數(shù)式編程平臺(tái)解決棘手的并行編程部分，函數(shù)式編程里大多數(shù)都是不可變的對(duì)象。Scala那種無(wú)共享，基于角色的消息傳遞并行機(jī)制是源于運(yùn)行在JVM外的Erlang語(yǔ)言（可參考51CTO之前發(fā)布的Scala和Erlang，以及多核主導(dǎo)的未來(lái)一文），這種機(jī)制很有前景。但是，這又是今后的另一個(gè)話題了。
原文：Is There Any Correct Java Code Out There?
作者：James Elliott
【相關(guān)閱讀】
