JavaOne 2014参会总结

4年前我参加了一次JavaOne,这是第二次参加,JavaOne的形式上和4年前完全一样,开会的地点、Rock Show、我无法适应的冷的午餐等也都一样。
JavaOne作为Java领域最高级别的会议(毕竟一众的Java大牛都在硅谷),总是会让人或多或少得到一些收获,尽管也会有一些水的Topic,我对一起参会的同事说,这种会议要么拓宽视野(就是听一些和自己工作可能完全无关的领域的状况),要么就是深入学习(JavaOne上不太缺深入的Topic)。

这次JavaOne我总计参加了20个Topic,分别来回顾下:
1. What’s up with modularity?
这是早上8:30–10:30的TUT性质的Topic,因此主要是现场用OSGi叫大家写模块化的代码,相对来说自己对这块还比较熟悉,唯一的感触是现在开发上貌似比以前成熟了一些。

2. Multitenant Java for High-Density Cloud Deployments
这个方向是自己比较感兴趣的,IBM做为这方面做的还不错的,确实值得听听,听下来最大的感触是:
* 这东西的实现机制非常诡异,我到现在都不太明白为什么IBM是采用多进程的方式来实现,我还想着如果是多进程的方式,那类似GC等问题就没了,另外像资源隔离等也就可以用类似cgroup来实现了;
* 这东西的成熟度我表示很质疑,例如要去解决全局的static、System.exit等问题,那会不会出现遗漏的点,这个其实有点象Linux Container的情况下要控制Container的权限是一样的,挺容易出现覆盖不全的现象,而这个的后果会比Container糟糕很多,因为搞不好是数据被篡改了什么的;
* 这东西的资源隔离上做的不成熟,现场的Demo来看cpu等控制的抖动非常严重。
所以我听完这个topic的唯一感觉就是,这个方向估计有点悬;

3. HTTP 2.0 comes to Java: What Servlet 4.0 Means to You
这个印象不怎么深了,总的来说就是Servlet 4.0会增加一些HTTP 2.0特性的接口,例如服务端的推送等;

4. ARM: Over 10 Billion Serverd
这场就是我说的希望拓宽视野的Topic,听这场的人非常少,连讲的同学都开玩笑说:果然是JavaOne,:)
这场听到的就是原来Java跑在ARM上是没问题的,但性能等很多方面差距还不小,例如64 bit暂时是不支持的,性能上Java的内存模型相关的指令优化ARM上是没有的。
听下来的感觉就是Java Server端要跑在ARM上还有很长的路要走。

5. Java Performance Is a Social Activity
这场真心没什么印象了,貌似主要还是强调Performance是要多人合作的。

6. Java Performance: Hardware, Structures, and Algorithms
这场是大牛讲的,topic的重点是Java Performance和硬件、数据结构等的关系,我印象最深的就是PPT上的工具截图,看起来是个非常NB的工具,可以显示到每行代码对CPU的消耗等,如果有同学知道是什么工具,麻烦告诉下。
另外大牛说很多Java应用对cpu cache使用的不够好,导致了performance不好,这个点话说之前真没太关注过,看来之后要试验下这个方向。
我和一起参会的同事说,这个Topic的重点是吐槽Java开发对硬件了解的太少,:)

7. Preventing Errors Before They Happen
也是一个TUT,主要是教大家用Type Checker来做编译期就把一些问题搞定的方法,例如参数是否null之类的。

8. where is my memory?
这个和上一个topic是同一个时间点,我稍微听了下上个topic就跑来听这个了,也是一个TUT,例如教大家怎么用jmap dump内存,怎么用MAT去分析,说实话,这个如果是阿里的同学讲我觉得可以讲的更全面,因为我们几乎碰过所有的Java Memory问题。

9. Java Concurrency Under The Hood
这个Topic超出了我的预期,必须给最高评价,按照大家比较一直的感觉是,JavaOne的topic不现场show或写代码,那压根都不好意思登场,这个Topic更狠,现场带着大家看JVM源码,来理解voliate Java是怎么实现的,这个太赞了,至少可以学习到一个如果从bytecode引导到JVM源码的方法(授人以鱼不如授人以渔),这种topic就必须现场听了(不过JavaOne很多都是现场写代码什么,所以很多PPT上都看不出什么)。
另外现场的一次举手中发现老外用Java 7的比例还真不低。

10. Java 8 Concurrency and Collections: what’s New
印象不算很深,因为几点改进之前也有一些了解。

11. Put a Firewall in Your JVM: Securing Java Applications
也是一个用于拓宽视野的topic,成功的做到了,至少它的做法让我觉得比较新鲜,我第一次看到直接在运行时来判断是否安全的做法,例如sql注入,它会判断运行的sql是否安全,如果不安全直接就屏蔽了,这种做法的好处是应用层面不需要改,直接底层就控制住了,例如现场还演示了如何修复struts bug,也是不需要修改struts代码。
这是一个商用的软件,觉得会有一些市场(例如现场就是一个银行的客户一起讲这个topic),毕竟要让写Java的同学都清楚怎么写安全的代码的难度还是不小的,尽管这种的做法应该会影响一些性能。

12. Is Your Code Parallel-Ready?
很多人吐槽这次JavaOne里关于Java 8 Streaming的topic太多了,确实,这也是其中一个,这个改进固然好,不过用那么多topic来讲就没必要了吧,对Streaming了解不多的同学可以去google看看。

13. Continuous Delivery and Zero Downtime
印象最深的就是有一页PPT上写着:No Deploy with snapshots,这个应该戳中了很多人的痛点吧,我们出现过多次因为Snapshot造成的故障…
其他的印象不算深…

14. Principles of Evolutionary Architecture
印象不深,我还是喜欢听show code的topic,:),这种原则性的听起来感觉不强烈,而且她里面讲到的例如make a decision as later as u can,这句其实我不是很赞同,在一个大规模的系统里,很多时候是需要有一些前瞻动作的。

15. Debugging and Profiling Robots with James Gosling
这个topic,大部分人显然是冲着Gosling去的,topic内容就是现场演示用JAVA控制的pi、飞行器等,Gosling的话是做了用java控制的在海上漂的小船之类的,这个topic最搞的是到问题阶段的时候,N多人问Gosling做了这个了是不是可以改行做fishman了,:)
topic一结束,N多人就拿着相机在拍Gosling…

16. Java in the Cloud: The Good Parts
这貌似是唯一的一个Google讲的Topic,印象深的就是Google显然主推docker,另外就是现场演示的cloud debugger好NB,在页面上设置一个断点,刷新页面,然后会跳入这个断点,这个真的太有需求了…

17. Understanding Latency and Response Time
这个topic最重要的是告诉大家不仅仅要看平均响应时间,还得看响应时间的分布,我们在这件事上是已经吃过亏的,平均响应时间很多时候抹掉了太多的问题,这个topic的PPT强烈推荐大家看看。

18. With GC Solved, what else makes a JVM pause?
这场我到的时候已经快结束了,不过我简单听下能感觉到这个topic还是很值得学习的,不过因为不属于show or write code的,所以可以download ppt来学习,这个topic讲了下除了GC会导致应用暂停外,还有哪些也会,其实知道这个是很重要的,例如jmap -histo:live也会,如果不知道有可能在生产环境随意执行,就会直接导致故障。

19. What’s cool in SAP JVM?
听这个topic的人非常的少,可能只有10个人,对我来说拓宽视野更重要,所以就去听了,至少现场演示的SAP JVM的allocation objects那个功能真心很需要,这个对性能优化等会有很大的帮助。

20. Virtualization-Aware Java
这是IBM的topic,一个小时的topic只讲了半个小时,真心没什么收获,重点强烈的就是JVM层面如何感知在什么虚拟化环境下,应该做什么相应的动作,这个我们采用的方法都是在内核层直接处理掉,无需JVM层面来知晓。

总的下来,我对JavaOne的评价是值得参加的,毕竟对视野的开阔、想深入了解的技术部分都会有一定的帮助,有些甚至能在参会后就形成一些Actions,这就足以了,现场Azul、Oracle的Topic质量都还不错,IBM的真心不咋样,不过话说我觉得阿里如果去讲讲Java支撑大型网站的架构,阿里碰到的一些Java问题的话,应该会更加吸引人,:)

=============================
欢迎关注微信公众号:hellojavacases

关于此微信号:
分享Java问题排查的Case、Java业界的动态和新技术、Java的一些小知识点Test,以及和大家一起讨论一些Java问题或场景,这里只有Java细节的分享,没有大道理、大架构和大框架。

公众号上发布的消息都存放在http://hellojava.info上。

JavaOne 2013

JavaOne是每年Java领域最值得关注的大会(当然,我说的是美国版本的),JavaOne的质量基本是可以有保障的,原因也很容易理解,毕竟大部分做JVM相关的人都就在SF,前几年去现场参加的很多场景还记忆犹新,见到一大堆的传说中的高人,不扯这些了,来说说今年的几个让自己觉得值得看看的session。

1. Fault tolerance made easy
貌似以前的JavaOne上很少这种话题,如何构建可容灾的系统,是互联网类型的大会上比较常见的topic,这个topic总结了一些常见的构建可容灾系统的模式,挑选几个说下:
超时
这个真心是容易导致系统出问题的一个常见问题,意思主要是所有的阻塞调用的地方都要带上超时,否则很容易因为依赖的系统响应慢或其他原因,而把自己系统的处理线程全部拖S,topic里举的例子也很直白:
object.wait(); // 不要用这种方式
object.wait(TIMEOUT); // 应该用这种

Fail Fast
这个是高可用系统的基本策略,在需要使用到的资源不可用的时候,应立刻抛错,而不是一直等待,例如最典型的是在处理线程池满了的情况下,不应该放进队列等,而应该直接拒绝,这是在线系统高可用的一个基本原则,可以接受快速的失败,但不能接受长时间的等待,和离线系统是不同的。

Shed Load
类似负载保护的意思,这个我觉得他举的实现的例子一般吧,那样做其实是会有些问题的,这个确实很有必要,以前我们没做的时候,经常会出现一台机器load狂飙,然后后来登录不上去了,所以问题都没法处理。

Limited Retries
这个也是需要注意的,如果重试的动作一直失败,就很容易导致系统被卡S,这和超时那个其实类似,一般来说,在线系统应尽可能不做重试,除非一些必要的场景,而对于必要的重试场景,通常建议的是采取避让的机制。

关于构建高可用的系统的一些常见方法,也欢迎大家看看我写的一篇blog

2. Java 8 Collections and Concurrency
从这个PPT里可以看到Java 8里的集合对象在并发场景的一些优化,例如提供新的LongAdder,在多线程的情况下对比目前的AtomicLong会快很多。
ConcurrentHashMap也将进一步的优化,这对大部分应用来说都是好消息。
增加一个更优秀的读写锁的实现:StampedLock
对HashMap的优化,主要是尽可能降低hash冲突时链表长的现象。

3. Java Memory Hogs
这个topic很不错,值得细致的看看,摘几句话:
“Java Memory usage is typically 2x of C++ programs”,这里的主要原因有两个,一是Java的数据结构描述本身占的内存实在是多了点,二是多数Java程序员在选择数据结构的时候不会考虑这个问题,这也是屏蔽细节带来的问题,当然,也可以认为是为了提升开发效率的一个折衷。
“Most Popular objects: String, char[], Object[], ArrayList, HashMap”,这是统计的占用java heap的最常见的对象,确实差不多就是这些,对于分布式系统来说,byte[]也会是主力。
“Don’t encode numbers into Strings (0.4% heap wasted).” 看起来貌似浪费不严重,但积少成多。
“Use String.intern() in non-performance critical code.” 这话很伤人呀,因为JDK自己的很多地方都用到了String.intern,哎,现在这个绝对是个cpu消耗的主力,尤其是在之前StringTableSize不能调的JDK版本里。
“Programs need to lazily create the Object[ ]” “Better optimization: Don’t create collections until last moment possible.”在不少的应用里,都会有大量的empty Object[],而这些也是会占掉一些heap的,因此最好能在要用的时候才去初始化,例如ArrayList、HashMap等等。
“Hash collections could use an array instead.”在有些场景是值得这么做的,可以减少内存消耗。
“Properly size the capacity of the collection.”这个真心没有多少人会关注,但基本是造成内存浪费的一个主要原因,因为collection等在做auto expand的时候,之前的数组对象等其实都还是活着的…
“Percentage of memory saved for each optimization.Total savings: 63.7% Worth millions in saved hardware per data center.” 我以前其实也觉得上面说的那些小的使用技巧会有多大的帮助,但从目前我们的很多应用来看,在gc上确实浪费了不少的cpu,而之所以gc这么多,其实也就是因为上面的这些小技巧不是人人都重视,导致了内存的严重浪费,但悲催的是这个没法从语言层面做,而如果只是个别程序员重视,效果是不突出的,这是个杯具,所以说一个优秀的Java程序员写出来的Java代码会比普通的强很多很多,现在我表示越来越认同了。

4. Memory-Efficient java
这个Topic先告诉了下大家Java的对象结构的内存浪费现象,潜台词就是大家在写代码的时候应该特别注意数据结构的选择以及使用方法 “Objects are (much) larger than the data you store in them” “Using the wrong type of collection can incur significant additional memory overhead”。
举了个例子来分析里面的空的集合对象:“Over 50% of collections are empty in our example”,关注的同学可以看看,是利用Mat来分析的一种常用方法。
这个Topic和上面一个有些类似,都告诉了大家尽管Java是自行管理内存的,但如果你写代码的时候随便用,就会很大程度的浪费内存,从而造成GC的压力,从而造成无谓的CPU浪费,最终导致系统的处理能力下降。
但悲催的就是这些都是写代码的技巧,而不是语言层面的自动优化,所以这个时候优秀的程序员和普通程序员的区别就会非常明显。

5. Understanding GC
这是Azul的同学讲的一个Topic,貌似之前在其他什么会上也讲过,挺经典的,这个Topic里简单的讲了下GC实现的基本原理,顺带“吹嘘”了下Zing的“C4” collector,是全不暂停的,所以在大内存的情况下优势明显。
众所周知现在在大内存的场景下,Java确实很悲催,GC问题,内存排查问题等等…

除了上面说的这几个PPT外,还有不少不错的PPT,不过由于在其他的大会上见过,新内容不多,所以我就没列了,例如
Advanced JVM Tuning、Looking into jvm crystal ball,感兴趣的同学可以自行到JavaOne的官网上下载感兴趣的slides。

=============================
欢迎关注微信公众号:hellojavacases

关于此微信号:
分享Java问题排查的Case、Java业界的动态和新技术、Java的一些小知识点Test,以及和大家一起讨论一些Java问题或场景,这里只有Java细节的分享,没有大道理、大架构和大框架。

公众号上发布的消息都存放在http://hellojava.info上。