2017 JavaOne參會感想

國慶期間有幸做爲表明和另外 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…