國(guó)慶期間有幸作為代表和另外 6 位同學(xué)去舊金山參加 JavaOne 大會(huì)，本次大會(huì)我關(guān)注的幾個(gè)關(guān)鍵的 points： AJDK 在 Java 9 的 Keynote 主場(chǎng)公開亮相，Kingsum 為全場(chǎng)聽眾講解了 AJDK 如何與 Intel 等硬件商場(chǎng)深度合作，支撐了雙 11 全球最大的購(gòu)物節(jié)。

國(guó)慶期間有幸作為代表和另外 6 位同學(xué)去舊金山參加 JavaOne 大會(huì)，本次大會(huì)我關(guān)注的幾個(gè)關(guān)鍵的 points：

AJDK 在 Java 9 的 Keynote 主場(chǎng)公開亮相，Kingsum 為全場(chǎng)聽眾講解了 AJDK 如何與 Intel 等硬件商場(chǎng)深度合作，支撐了雙 11 全球最大的購(gòu)物節(jié)。

Java 9 的新特性，以模塊化為代表。

Serverless、Cloud Native 架構(gòu)。

微服務(wù)和 DevOps 的結(jié)合。

下面記錄一些感覺相對(duì)有啟發(fā)的 info 帶著我個(gè)人的一些想法：

Java Keynote

Alibaba JDK

這一場(chǎng)應(yīng)該是本次大會(huì)對(duì) Java 9 和 Java 生態(tài)而言最光鮮的亮相，三紅提前劇透了說(shuō)會(huì)有驚喜，結(jié)果真的是個(gè)大驚喜，Kingsum 代表阿里巴巴把 AJDK 在這個(gè) Keynote 上公開 show 了一把，包括實(shí)例數(shù)、性能改進(jìn)、多租戶、WISP 協(xié)程、JITWarmUp 等特性簡(jiǎn)直亮瞎了，比較自豪。

Intel

看贊助商列表的時(shí)候看到 Intel 是 TOP 1，剛在想作為一個(gè)硬件廠商和 Java 9 發(fā)布有什么關(guān)系時(shí)，Intel 的 VP 就解答了這個(gè)疑問(wèn)，Intel 還是比較有危機(jī)感，除了芯片還在做非常多和軟件特別是語(yǔ)言底層緊密結(jié)合的事情，10 年來(lái) Intel 使得 Java 的性能提升了 73 倍，比如 Intel 也在搞 AI 戰(zhàn)略，他們的思路是要做 AI 的 infrastructure，例如 AVX512 指令集，針對(duì)向量計(jì)算相比上一代有 8~16 倍的提升，還不僅于此，Intel 直接發(fā)布了 Vector API SDK 讓 Java 程序員可以用 Java API 去充分壓榨硬件的向量計(jì)算性能，在過(guò)去是需要用 JNI 去調(diào)用 low-level API 實(shí)現(xiàn)的事情，現(xiàn)在可以用 PureJava 了。

Intel 在存儲(chǔ)上也有不少創(chuàng)新，非易失內(nèi)存 3D-XPoint 和 Optane SSD 的發(fā)布（對(duì)于二者的區(qū)別 Session 結(jié)束后問(wèn)了下，前者是基于 byte 裸訪問(wèn)的，后者還是面向 Block 和文件系統(tǒng)），結(jié)合 pmem 庫(kù)的支持（還在 pilot flight 開發(fā)階段），對(duì)未來(lái)幾年的存儲(chǔ)軟件有很大的利好，褚霸團(tuán)隊(duì)的 PolarDB 似乎也是用的 Optane。

針對(duì)深度學(xué)習(xí)開源了 BigDL 框架，Scala/Python 也都支持，Intel 決心還是有的。

其它

Spotify 分享了下如何從 Python 遷移到 Java，背了個(gè)書。

Kubernetes 已經(jīng)成為容器調(diào)度實(shí)際的主流，發(fā)布了 Wercker 在線性能診斷工具，相比 Cloud Native 提出了 Container Native 的概念，有一系列的本地工具提高對(duì)開發(fā)者的友好度。

Java 9 開始提供了 jlink 這個(gè)新工具，需要結(jié)合 module 一起用，能夠只打包用到的 JRE 模塊，大幅縮小容器鏡像的大小（對(duì) Container 微服務(wù)比較有用）。

Java 9 引入了 AOT，不過(guò)目前還非常 experimental 的階段，生產(chǎn)環(huán)境還為時(shí)尚早。

JUG 社區(qū)氛圍

國(guó)內(nèi)在 Java 社區(qū)這一塊的氛圍感覺遠(yuǎn)不如 Go/Node.JS/Python/Ruby 等語(yǔ)言的社區(qū)，一定程度上是因?yàn)?Java 程序員數(shù)量比較多，比較少抱團(tuán)，另一方面 Java 程序員一般都在做企業(yè)級(jí)的應(yīng)用，平時(shí)和社區(qū)交流的機(jī)會(huì)也少一些。不少講師都有一個(gè) Java Champion 的頭銜，查了一下，這個(gè)冠軍程序員不光要求技能過(guò)關(guān)，而且要在社區(qū)上投入足夠多的精力和時(shí)間，得到社區(qū)認(rèn)可的人才可以獲此殊榮。

國(guó)外的 JUG 發(fā)展非常火熱，幾乎每個(gè)城市甚至一個(gè)城市會(huì)有 2 個(gè)以上的 JUG，聽了一場(chǎng)芝加哥 JUG 的負(fù)責(zé)人的 Session，大家都在談 JCP，關(guān)于建設(shè)社區(qū)的一些 points：

尊重社區(qū)里的 members，不要泄露別人隱私 like email，不然會(huì)被懲罰

傳播信息時(shí)要精確的信息（比如不要用『第一個(gè)工作日、這周的休息日』這樣的描述），每個(gè)成員來(lái)自不懂的地域，習(xí)俗不同，比如有些地方是周一休息

冷啟動(dòng) JUG 比較好的方式：參加別的會(huì)議看是否有同城來(lái)的，social 拉攏一下

lightening talk，每個(gè)人 5 到 10 分鐘，讓每個(gè)人都有表達(dá)的機(jī)會(huì)

整體感覺雖然是技術(shù)社區(qū)，但很 social beings，雖然工程師都比較 nerd

內(nèi)部認(rèn)同感很強(qiáng)，有種巫師秘密集會(huì)的感覺

后來(lái)我也跟坤谷聊了下這個(gè)問(wèn)題，有機(jī)會(huì)的話后面希望能為我們自己的 JUG 做一些貢獻(xiàn)。

關(guān)于 Java 未來(lái)發(fā)展

這一場(chǎng)找了一些 Java 社區(qū)中的活躍者，基本上是一些 Java 生態(tài)創(chuàng)業(yè)公司的技術(shù)負(fù)責(zé)人的角色，例如 Azul JVM，也有 Oracle/IBM/Google 這樣巨頭的 TL 來(lái)參加。

挑選幾個(gè)有價(jià)值的信息：

Oracle 向社區(qū)捐贈(zèng) JavaEE，同時(shí)最新的 JavaEE 8 也發(fā)布了，社區(qū)比較興奮，準(zhǔn)備大干一場(chǎng)，例如 Eclipse MicroProfile 等社區(qū)，我們平時(shí)用 Spring 比較多，這塊其實(shí)關(guān)注度不太高，整體上 JavaEE 未來(lái)的發(fā)展會(huì)比過(guò)去更快

Google 目前在 JVM 生態(tài)上的投入，主要是維護(hù) CMS GC（Oracle 一定會(huì)推 G1，CMS 的代碼太老太復(fù)雜，維護(hù)成本太高，但是 Google 有需要），以及一些 OpenJDK 的 patch

Java 在 AI 方面，Mahout 和 Spark 這些基礎(chǔ)設(shè)施都是運(yùn)行在 JVM 之上，社區(qū)的人認(rèn)為 Java 在 AI 方面相比 Python 更成熟穩(wěn)定，所用的東西都是經(jīng)過(guò) 5 年以上考驗(yàn)的（這個(gè)么聽聽就好了:D）

對(duì)于 G1 的使用，Oracle 的同學(xué)表示還是要看具體 case，從他們的經(jīng)驗(yàn)看，目前對(duì)于 large heap 的場(chǎng)景 G1 還是有優(yōu)勢(shì)的，另外對(duì)于使用 G1 的公司，建議一定要保持用最新的 JDK，因?yàn)?G1 還在不斷修復(fù)優(yōu)化（是不是聽起來(lái)不太靠譜，這也是 Google 還要維護(hù) CMS 的原因之一吧）

Java 對(duì) GPU 計(jì)算的支持，目前 Project Sumatra 在試圖解決這個(gè)問(wèn)題，但是不太活躍，他們也請(qǐng)求大家能夠一起進(jìn)來(lái) contribute（多個(gè) Session 的分享人都講到了希望大家一起來(lái)改善和貢獻(xiàn)，有非常強(qiáng)的社區(qū)味道，這點(diǎn)國(guó)內(nèi)還比較弱）

有人問(wèn)到了 JNI 2 的問(wèn)題，Project Panama 正在嘗試更好地解決 Pure Java 和 Native Code 之間互通的問(wèn)題

關(guān)于并發(fā)編程，社區(qū)不斷地提高線程模型的抽象程度，例如 ForkJoin、Actor 等，但對(duì)于協(xié)程依然沒有 official 的說(shuō)法，JVM 的協(xié)程在開源界已經(jīng)有部分支持了，但 runtime 還是比較少，不過(guò)回來(lái)以后看三紅講協(xié)程已經(jīng)被 proposal 了（http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html）

Java 作為一門不那么年輕的語(yǔ)言，今天有什么優(yōu)勢(shì)，大家還是比較有共識(shí)：生態(tài)，你想要的一切，在這個(gè)生態(tài)里幾乎都有，這一點(diǎn)是 Python、Go 很難追上的

JavaEE 8 開始在 GitHub 開源，社區(qū)做 contribute 效率更高了（https://github.com/javaee）

JVM 研發(fā)相關(guān)

Azul 是一家比較有特色的 JVM 公司，一般我們講 JVM 都是什么 Oracle、IBM、Google、Alibaba 這些大廠在搞，但是 Azul 獨(dú)樹一幟做到了 latency 極低的 GC 時(shí)間。

Azul CTO 講了下他們?cè)谧?JVM 過(guò)程中的一些思路，有一個(gè)印象比較深刻的點(diǎn)，和阿里云銷售的思路是比較像的。Azul 重新審視『快』的問(wèn)題，快到底是吞吐高、延遲低、還是別的，他們給客戶特別是交易系統(tǒng)推銷的時(shí)候，不會(huì)講我這個(gè)東西技術(shù)上多牛逼，GC 延遲相比 Oracle JVM 低多少，而是一套業(yè)務(wù)解決方案，告訴客戶用了我的你可以比別的券商快幾個(gè)毫秒完成交易，這也是客戶最看重的。

對(duì)于技術(shù)底層知識(shí)的用途，平時(shí)很多同學(xué)也會(huì)有疑問(wèn)，好像了解底層的東西對(duì)于業(yè)務(wù)開發(fā)并沒有什么幫助，Azul 的 CTO 是這么看的：也許你不懂也能干活，但是懂的人 keep it in mind，在關(guān)鍵時(shí)刻能讓你有思路解決別人解決不了的問(wèn)題。我覺得講的已經(jīng)很到位了。

還有一些細(xì)節(jié)，例如 volatile 在編譯器中的作用：不要 cache value。對(duì)于壓測(cè)預(yù)熱，我們壓測(cè)中有一些代碼是 if(EagleEye.getUserData("t")) 判斷是否壓測(cè)流量的，然后某些下游就不壓了，這個(gè)被稱為 fake msg，他認(rèn)為這類預(yù)熱對(duì)于 JIT 優(yōu)化沒有效果，不過(guò)我看也沒這么絕對(duì)，做系統(tǒng)很多時(shí)候是一種權(quán)衡和妥協(xié)。

Docker相關(guān)

分享人是 k8s team 的，臺(tái)灣人。

介紹了一些 dockerfile 的 tips：

寫到一行縮減 layer size

指定 user 不要用 root

公共鏡像的安全性目前無(wú)法很好保證（即便是 official 的），最好是自己 build 出來(lái)

https://stacksmith.bitnami.com/ 這個(gè)網(wǎng)站很實(shí)用，有點(diǎn)像 SpringBoot 那個(gè) start 的網(wǎng)站，選你要用的組件，自動(dòng)生成 Dockerfile 下載下來(lái) build

文件讀寫用 volume 掛載避免 layer 不斷增長(zhǎng)最后磁盤爆掉，

容器內(nèi)存限制和 jvm heap size 不聯(lián)動(dòng)（JVM 默認(rèn)會(huì)用宿主機(jī)的內(nèi)存大小），包括 CPU 也是，一般用 Runtime.getRuntime() 拿到的數(shù)據(jù)在 Docker 中已經(jīng)不準(zhǔn)了，可以用-XX:+UseCGroupMemoryLimitForHeap 這個(gè) 8u141 開始的試驗(yàn)性特性

從 Functional Programming 到 Reactive Programming

函數(shù)式編程以前 Java 程序員比較陌生，從 Java 8 引入 lambda 開始慢慢 popular 了。這次幾個(gè) Session 都提到了 Reactive 即響應(yīng)式編程，簡(jiǎn)單來(lái)說(shuō)就是面向異步數(shù)據(jù)流的編程。

這個(gè)思想在目前我們的工作中實(shí)際已經(jīng)在部分使用了，只是還沒上升到理論級(jí)別，例如將線程池的并發(fā)計(jì)算改造為基于消息的分布式并發(fā)計(jì)算，Reactive 的范式我相信和分布式計(jì)算一樣會(huì)給研發(fā)協(xié)作方式帶來(lái)一些改變，過(guò)去是靠同步 RPC 解耦，時(shí)間維度還是耦合的，現(xiàn)在是靠異步數(shù)據(jù)間進(jìn)一步在時(shí)間上也解耦。

我個(gè)人是比較喜歡這種方式的，但對(duì)于面向終端用戶的 UI 請(qǐng)求而言，很多時(shí)候還是要退化到同步模型去做。

最重要的是，它背后依賴的一個(gè)真實(shí)而殘酷的現(xiàn)實(shí)是，在分布式系統(tǒng)下，一切都只能為最終一致性而設(shè)計(jì)，如果你沒意識(shí)到這個(gè)問(wèn)題，要么是別人在給你兜底，要么是還沒出故障。

分享另外一場(chǎng) Session 的兩張圖，說(shuō)得非常到位：

關(guān)于 Serverless

Serverless 也是本次大會(huì)很多講師在布道的東西，我的感覺是 Serverless 目前比較實(shí)用的場(chǎng)景和過(guò)去 nginx 中的 lua 腳本很類似，特別在 CDN 等 Edge 節(jié)點(diǎn)上，比如 CDN 回源、圖片縮放、水印等，但是對(duì)于業(yè)務(wù)邏輯開發(fā)的場(chǎng)景還是不太適用，需要理性對(duì)待。

講師總結(jié)的這個(gè) drawbacks 我個(gè)人覺得還是比較中肯，在企業(yè)級(jí)開發(fā)中 Serverless 還有很長(zhǎng)的路要走：

總結(jié)

以上是生活随笔為你收集整理的2017甲骨文JavaOne参会感想的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。