国庆期间有幸作为代表和另外 6 位同学去旧金山参加 JavaOne 大会，本次大会我关注的几个关键的 points：

1. AJDK 在 Java 9 的 Keynote 主场公开亮相，Kingsum 为全场听众讲解了 AJDK 如何与 Intel 等硬件商场深度合作，支撑了双 11 全球最大的购物节。

2. Java 9 的新特性，以模块化为代表。

3. Serverless、Cloud Native 架构。

4. 微服务和 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：

1. 尊重社区里的 members，不要泄露别人隐私 like email，不然会被惩罚

2. 传播信息时要精确的信息（比如不要用『第一个工作日、这周的休息日』这样的描述），每个成员来自不懂的地域，习俗不同，比如有些地方是周一休息

3. 冷启动 JUG 比较好的方式：参加别的会议看是否有同城来的，social 拉拢一下

4. lightening talk，每个人 5 到 10 分钟，让每个人都有表达的机会

5. 整体感觉虽然是技术社区，但很 social beings，虽然工程师都比较 nerd

6. 内部认同感很强，有种巫师秘密集会的感觉

后来我也跟坤谷聊了下这个问题，有机会的话后面希望能为我们自己的 JUG 做一些贡献。

关于 Java 未来发展

这一场找了一些 Java 社区中的活跃者，基本上是一些 Java 生态创业公司的技术负责人的角色，例如 Azul JVM，也有 Oracle/IBM/Google 这样巨头的 TL 来参加。

挑选几个有价值的信息：

1. Oracle 向社区捐赠 JavaEE，同时最新的 JavaEE 8 也发布了，社区比较兴奋，准备大干一场，例如 Eclipse MicroProfile 等社区，我们平时用 Spring 比较多，这块其实关注度不太高，整体上 JavaEE 未来的发展会比过去更快

2. Google 目前在 JVM 生态上的投入，主要是维护 CMS GC（Oracle 一定会推 G1，CMS 的代码太老太复杂，维护成本太高，但是 Google 有需要），以及一些 OpenJDK 的 patch

3. Java 在 AI 方面，Mahout 和 Spark 这些基础设施都是运行在 JVM 之上，社区的人认为 Java 在 AI 方面相比 Python 更成熟稳定，所用的东西都是经过 5 年以上考验的（这个么听听就好了:D）

4. 对于 G1 的使用，Oracle 的同学表示还是要看具体 case，从他们的经验看，目前对于 large heap 的场景 G1 还是有优势的，另外对于使用 G1 的公司，建议一定要保持用最新的 JDK，因为 G1 还在不断修复优化（是不是听起来不太靠谱，这也是 Google 还要维护 CMS 的原因之一吧）

5. Java 对 GPU 计算的支持，目前 Project Sumatra 在试图解决这个问题，但是不太活跃，他们也请求大家能够一起进来 contribute（多个 Session 的分享人都讲到了希望大家一起来改善和贡献，有非常强的社区味道，这点国内还比较弱）

6. 有人问到了 JNI 2 的问题，Project Panama 正在尝试更好地解决 Pure Java 和 Native Code 之间互通的问题

7. 关于并发编程，社区不断地提高线程模型的抽象程度，例如 ForkJoin、Actor 等，但对于协程依然没有 official 的说法，JVM 的协程在开源界已经有部分支持了，但 runtime 还是比较少，不过回来以后看三红讲协程已经被 proposal 了（

8. Java 作为一门不那么年轻的语言，今天有什么优势，大家还是比较有共识：生态，你想要的一切，在这个生态里几乎都有，这一点是 Python、Go 很难追上的

9. JavaEE 8 开始在 GitHub 开源，社区做 contribute 效率更高了（

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：

1. 写到一行缩减 layer size

2. 指定 user 不要用 root

3. 公共镜像的安全性目前无法很好保证（即便是 official 的），最好是自己 build 出来

4.  这个网站很实用，有点像 SpringBoot 那个 start 的网站，选你要用的组件，自动生成 Dockerfile 下载下来 build

5. 文件读写用 volume 挂载避免 layer 不断增长最后磁盘爆掉，

6. 容器内存限制和 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 还有很长的路要走：