國慶期間有幸作為代表和另外 6 位同學去舊金山參加 JavaOne 大會，本次大會我關注的幾個關鍵的 points：
AJDK 在 Java 9 的 Keynote 主場公開亮相，Kingsum 為全場聽眾講解了 AJDK 如何與 Intel 等硬體商場深度合作，支撐了雙 11 全球最大的購物節。
Java 9 的新特性，以模組化為代表。
Serverless、Cloud Native 架構。
微服務和 DevOps 的結合。
下面記錄一些感覺相對有啟發的 info 帶著我個人的一些想法：
Java Keynote
Alibaba JDK
這一場應該是本次大會對 Java 9 和 Java 生態而言最光鮮的亮相，三紅提前劇透了說會有驚喜，結果真的是個大驚喜，Kingsum 代表阿里巴巴把 AJDK 在這個 Keynote 上公開 show 了一把，包括例項數、效能改進、多租戶、WISP 協程、JITWarmUp 等特性簡直亮瞎了，比較自豪。
Intel
看贊助商列表的時候看到 Intel 是 TOP 1，剛在想作為一個硬體廠商和 Java 9 釋出有什麼關係時，Intel 的 VP 就解答了這個疑問，Intel 還是比較有危機感，除了晶片還在做非常多和軟體特別是語言底層緊密結合的事情，10 年來 Intel 使得 Java 的效能提升了 73 倍，比如 Intel 也在搞 AI 戰略，他們的思路是要做 AI 的 infrastructure，例如 AVX512 指令集，針對向量計算相比上一代有 8~16 倍的提升，還不僅於此，Intel 直接釋出了 Vector API SDK 讓 Java 程式設計師可以用 Java API 去充分壓榨硬體的向量計算效能，在過去是需要用 JNI 去呼叫 low-level API 實現的事情，現在可以用 PureJava 了。
Intel 在儲存上也有不少創新，非易失記憶體 3D-XPoint 和 Optane SSD 的釋出（對於二者的區別 Session 結束後問了下，前者是基於 byte 裸訪問的，後者還是面向 Block 和檔案系統），結合 pmem 庫的支援（還在 pilot flight 開發階段），對未來幾年的儲存軟體有很大的利好，褚霸團隊的 PolarDB 似乎也是用的 Optane。
針對深度學習開源了 BigDL 框架，Scala/Python 也都支援，Intel 決心還是有的。
其它
Spotify 分享了下如何從 Python 遷移到 Java，背了個書。
Kubernetes 已經成為容器排程實際的主流，釋出了 Wercker 線上效能診斷工具，相比 Cloud Native 提出了 Container Native 的概念，有一系列的本地工具提高對開發者的友好度。
Java 9 開始提供了 jlink 這個新工具，需要結合 module 一起用，能夠只打包用到的 JRE 模組，大幅縮小容器映象的大小（對 Container 微服務比較有用）。
Java 9 引入了 AOT，不過目前還非常 experimental 的階段，生產環境還為時尚早。
JUG 社群氛圍
國內在 Java 社群這一塊的氛圍感覺遠不如 Go/Node.JS/Python/Ruby 等語言的社群，一定程度上是因為 Java 程式設計師數量比較多，比較少抱團，另一方面 Java 程式設計師一般都在做企業級的應用，平時和社群交流的機會也少一些。不少講師都有一個 Java Champion 的頭銜，查了一下，這個冠軍程式設計師不光要求技能過關，而且要在社群上投入足夠多的精力和時間，得到社群認可的人才可以獲此殊榮。
國外的 JUG 發展非常火熱，幾乎每個城市甚至一個城市會有 2 個以上的 JUG，聽了一場芝加哥 JUG 的負責人的 Session，大家都在談 JCP，關於建設社群的一些 points：
尊重社群裡的 members，不要洩露別人隱私 like email，不然會被懲罰
傳播資訊時要精確的資訊（比如不要用『第一個工作日、這周的休息日』這樣的描述），每個成員來自不懂的地域，習俗不同，比如有些地方是週一休息
冷啟動 JUG 比較好的方式：參加別的會議看是否有同城來的，social 拉攏一下
lightening talk，每個人 5 到 10 分鐘，讓每個人都有表達的機會
整體感覺雖然是技術社群，但很 social beings，雖然工程師都比較 nerd
內部認同感很強，有種巫師祕密集會的感覺
後來我也跟坤谷聊了下這個問題，有機會的話後面希望能為我們自己的 JUG 做一些貢獻。
關於 Java 未來發展
這一場找了一些 Java 社群中的活躍者，基本上是一些 Java 生態創業公司的技術負責人的角色，例如 Azul JVM，也有 Oracle/IBM/Google 這樣巨頭的 TL 來參加。
挑選幾個有價值的資訊：
Oracle 向社群捐贈 JavaEE，同時最新的 JavaEE 8 也釋出了，社群比較興奮，準備大幹一場，例如 Eclipse MicroProfile 等社群，我們平時用 Spring 比較多，這塊其實關注度不太高，整體上 JavaEE 未來的發展會比過去更快
Google 目前在 JVM 生態上的投入，主要是維護 CMS GC（Oracle 一定會推 G1，CMS 的程式碼太老太複雜，維護成本太高，但是 Google 有需要），以及一些 OpenJDK 的 patch
Java 在 AI 方面，Mahout 和 Spark 這些基礎設施都是執行在 JVM 之上，社群的人認為 Java 在 AI 方面相比 Python 更成熟穩定，所用的東西都是經過 5 年以上考驗的（這個麼聽聽就好了:D）
對於 G1 的使用，Oracle 的同學表示還是要看具體 case，從他們的經驗看，目前對於 large heap 的場景 G1 還是有優勢的，另外對於使用 G1 的公司，建議一定要保持用最新的 JDK，因為 G1 還在不斷修復優化（是不是聽起來不太靠譜，這也是 Google 還要維護 CMS 的原因之一吧）
Java 對 GPU 計算的支援，目前 Project Sumatra 在試圖解決這個問題，但是不太活躍，他們也請求大家能夠一起進來 contribute（多個 Session 的分享人都講到了希望大家一起來改善和貢獻，有非常強的社群味道，這點國內還比較弱）
有人問到了 JNI 2 的問題，Project Panama 正在嘗試更好地解決 Pure Java 和 Native Code 之間互通的問題
關於併發程式設計，社群不斷地提高執行緒模型的抽象程度，例如 ForkJoin、Actor 等，但對於協程依然沒有 official 的說法，JVM 的協程在開源界已經有部分支援了，但 runtime 還是比較少，不過回來以後看三紅講協程已經被 proposal 了（cr.openjdk.java.net/~rpressler/…
Java 作為一門不那麼年輕的語言，今天有什麼優勢，大家還是比較有共識：生態，你想要的一切，在這個生態裡幾乎都有，這一點是 Python、Go 很難追上的
JavaEE 8 開始在 GitHub 開源，社群做 contribute 效率更高了（github.com/javaee）
JVM 研發相關
Azul 是一家比較有特色的 JVM 公司，一般我們講 JVM 都是什麼 Oracle、IBM、Google、Alibaba 這些大廠在搞，但是 Azul 獨樹一幟做到了 latency 極低的 GC 時間。
Azul CTO 講了下他們在做 JVM 過程中的一些思路，有一個印象比較深刻的點，和阿里雲銷售的思路是比較像的。Azul 重新審視『快』的問題，快到底是吞吐高、延遲低、還是別的，他們給客戶特別是交易系統推銷的時候，不會講我這個東西技術上多牛逼，GC 延遲相比 Oracle JVM 低多少，而是一套業務解決方案，告訴客戶用了我的你可以比別的券商快幾個毫秒完成交易，這也是客戶最看重的。
對於技術底層知識的用途，平時很多同學也會有疑問，好像瞭解底層的東西對於業務開發並沒有什麼幫助，Azul 的 CTO 是這麼看的：也許你不懂也能幹活，但是懂的人 keep it in mind，在關鍵時刻能讓你有思路解決別人解決不了的問題。我覺得講的已經很到位了。
還有一些細節，例如 volatile 在編譯器中的作用：不要 cache value。對於壓測預熱，我們壓測中有一些程式碼是 if(EagleEye.getUserData(“t”)) 判斷是否壓測流量的，然後某些下游就不壓了，這個被稱為 fake msg，他認為這類預熱對於 JIT 優化沒有效果，不過我看也沒這麼絕對，做系統很多時候是一種權衡和妥協。
Docker相關
分享人是 k8s team 的，臺灣人。
介紹了一些 dockerfile 的 tips：
寫到一行縮減 layer size
指定 user 不要用 root
公共映象的安全性目前無法很好保證（即便是 official 的），最好是自己 build 出來
stacksmith.bitnami.com/ 這個網站很實用，有點像 SpringBoot 那個 start 的網站，選你要用的元件，自動生成 Dockerfile 下載下來 build
檔案讀寫用 volume 掛載避免 layer 不斷增長最後磁碟爆掉，
容器記憶體限制和 jvm heap size 不聯動（JVM 預設會用宿主機的記憶體大小），包括 CPU 也是，一般用 Runtime.getRuntime() 拿到的資料在 Docker 中已經不準了，可以用-XX:+UseCGroupMemoryLimitForHeap 這個 8u141 開始的試驗性特性
從 Functional Programming 到 Reactive Programming
函數語言程式設計以前 Java 程式設計師比較陌生，從 Java 8 引入 lambda 開始慢慢 popular 了。這次幾個 Session 都提到了 Reactive 即響應式程式設計，簡單來說就是面向非同步資料流的程式設計。
這個思想在目前我們的工作中實際已經在部分使用了，只是還沒上升到理論級別，例如將執行緒池的併發計算改造為基於訊息的分散式併發計算，Reactive 的正規化我相信和分散式計算一樣會給研發協作方式帶來一些改變，過去是靠同步 RPC 解耦，時間維度還是耦合的，現在是靠非同步資料間進一步在時間上也解耦。
我個人是比較喜歡這種方式的，但對於面向終端使用者的 UI 請求而言，很多時候還是要退化到同步模型去做。
最重要的是，它背後依賴的一個真實而殘酷的現實是，在分散式系統下，一切都只能為最終一致性而設計，如果你沒意識到這個問題，要麼是別人在給你兜底，要麼是還沒出故障。
分享另外一場 Session 的兩張圖，說得非常到位：
關於 Serverless
Serverless 也是本次大會很多講師在佈道的東西，我的感覺是 Serverless 目前比較實用的場景和過去 nginx 中的 lua 指令碼很類似，特別在 CDN 等 Edge 節點上，比如 CDN 回源、圖片縮放、水印等，但是對於業務邏輯開發的場景還是不太適用，需要理性對待。
講師總結的這個 drawbacks 我個人覺得還是比較中肯，在企業級開發中 Serverless 還有很長的路要走：
我有幾張阿里雲幸運券分享給你，用券購買或者升級阿里雲相應產品會有特惠驚喜哦！把想要買的產品的幸運券都領走吧！快下手，馬上就要搶光了。promotion.aliyun.com/ntms/act/am…