2017 JavaOne参会感想

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

  1. AJDK 在 Java 9 的 Keynote 主场公开亮相,Kingsum 为全场听众讲解了 AJDK 如何与 Intel 等硬件商场深度合作,支撑了双 11 全球最大的购物节。
  2. Java 9 的新特性,以模块化为代表。
  3. Serverless、Cloud Native 架构。
  4. 微服务和 DevOps 的结合。

下面记录一些感觉相对有启发的 info 带着我个人的一些想法:

继续阅读

Swap对响应时间敏感应用的影响

最近排查的一个线上应用load高的问题,和GC以及Swap有关系。

现象是机器load突然升高,查看占用CPU的线程发现是JVM自己的线程。

jstat发现一个奇怪的现象,Eden Gen到了100%之后会持续好几秒,但Old Gen没有明显增大,说明并不是Eden Gen不够用promote到Old Gen了,感觉似乎是Young GC出了问题。

进一步查看GC Log,发现一次Young GC要1秒多,正常情况下20~30ms都应该结束了。

然而仔细去看那条log会发现CPU消耗并不高:

[Times: user=0.23 sys=0.00, real=1.31 secs]

多出来的时间如果不在CPU上,那就是耗在了I/O上了,GC的I/O不会在网络上,只能是磁盘了。

free -m看了下,果然Swap的空间快被用满了都。

在排查到最终的内存原因前,先把Swap关掉:

sudo swapoff -a

对于Web应用等对响应时间(rt)非常敏感的系统来说,关闭Swap通常都是一个好的实践。

因为一般来说宁愿应用OOM挂掉也不愿意导致rt飙高,使得应用hang在那里的。

另外建议开启这两个参数:

-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=path

帮助你在发生OOM时dump heap,一般这时候的heap dump质量都比较高:)

面向GC的Java编程

Java程序员在编码过程中通常不需要考虑内存问题,JVM经过高度优化的GC机制大部分情况下都能够很好地处理堆(Heap)的清理问题。以至于许多Java程序员认为,我只需要关心何时创建对象,而回收对象,就交给GC来做吧!甚至有人说,如果在编程过程中频繁考虑内存问题,是一种退化,这些事情应该交给编译器,交给虚拟机来解决。

这话其实也没有太大问题,的确,大部分场景下关心内存、GC的问题,显得有点“杞人忧天”了,高老爷说过:

过早优化是万恶之源。

但另一方面,什么才是“过早优化”?

If we could do things right for the first time, why not?

事实上JVM的内存模型( JMM )理应是Java程序员的基础知识,处理过几次JVM线上内存问题之后就会很明显感受到,很多系统问题,都是内存问题。

对JVM内存结构感兴趣的同学可以看下 浅析Java虚拟机结构与机制 这篇文章,本文就不再赘述了,本文也并不关注具体的GC算法,相关的文章汗牛充栋,随时可查。

另外,不要指望GC优化的这些技巧,可以对应用性能有成倍的提高,特别是对I/O密集型的应用,或是实际落在YoungGC上的优化,可能效果只是帮你减少那么一点YoungGC的频率。

但我认为,优秀程序员的价值,不在于其所掌握的几招屠龙之术,而是在细节中见真著,就像前面说的,如果我们可以一次把事情做对,并且做好,在允许的范围内尽可能追求卓越,为什么不去做呢继续阅读

一次CMS GC的调优工作

某台机器的内存比较大,之前的JVM参数是4G的堆,在压测过程中发现当QPS上来以后,Full GC会开始抬头,YoungGC的频率就不用说了,比较高。

观察GC日志和jstat -gcutil,感觉是QPS在峰值的时候对象创建比较多,也有大对象产生。于是打算加大堆的大小来延缓GC的时机,并且有一些GC参数的优化,反复调整后找到了一个适合我们的参数(没有一个best的参数,还是得按照应用的的情况去测量,最好是一遍压测一遍调整,最终找到一个best fit的参数组)。

在把堆调大的过程中比较担心下面几个问题:

1、GC的压力会不会增大?

2、一次GC的耗时会不会增加?

3、如果在GC stop-the-world的时间里,rt飙高怎么办? 继续阅读

何时对null值做Cache

前几天发现某个系统对某个远程调用接口的调用量大幅上升,涨幅不可思议。根据接口调用上升的时间点和发布记录,查看SVN提交记录,发现是在系统主路径中添加了这个接口的调用,难道这个接口没有做Cache吗?仔细一看,倒是也做了Cache,并且这个RPC对应的DB表的数据量非常小,按理说是能全部被缓存起来的。那么为什么会反复调用,看起来仿佛没有Cache一样呢?

直觉是缓存被不存在的数据击穿了,马上验证。

通过对系统方法的追踪,发现每次调用传入的参数都是0,再去DB里面查,0对应的结果确实为空。

所以这是一个典型的因为空记录导致的缓存被击穿的案例。

解决方法很简单,对不存在的记录做一个null的Cache,下次就不会落到远端了。不过这里结合业务的特定场景,我只是加了一个判断,当值大于0才会去查询,这样连一次查询Cache的开销也省掉了。

这个简单的问题可以衍生出一些思考。 继续阅读

用AtomicStampedReference解决ABA问题

在运用CAS做Lock-Free操作中有一个经典的ABA问题:

线程1准备用CAS将变量的值由A替换为B,在此之前,线程2将变量的值由A替换为C,又由C替换为A,然后线程1执行CAS时发现变量的值仍然为A,所以CAS成功。但实际上这时的现场已经和最初不同了,尽管CAS成功,但可能存在潜藏的问题,例如下面的例子:

继续阅读