2017 JavaOne参会感想

国庆期间有幸作为代表和另外 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 了（http://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html）
8. Java 作为一门不那么年轻的语言，今天有什么优势，大家还是比较有共识：生态，你想要的一切，在这个生态里几乎都有，这一点是 Python、Go 很难追上的
9. JavaEE 8 开始在 GitHub 开源，社区做 contribute 效率更高了（https://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：

1. 写到一行缩减 layer size
2. 指定 user 不要用 root
3. 公共镜像的安全性目前无法很好保证（即便是 official 的），最好是自己 build 出来
4. https://stacksmith.bitnami.com/ 这个网站很实用，有点像 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 还有很长的路要走：