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上。

发表评论

电子邮件地址不会被公开。 必填项已用*标注


*