JSF 网站优化实战(一)

title img jsf opt

JVM调优和问题诊断是一个老生常谈,而又总也谈不好、谈不完的话题。常常是在本地开发、调试,甚至测试都没啥问题,一旦上线就纰漏百出,这种情况不鲜见,个人小项目、公司产品甚至大公司的产品多少都会遇到和 JVM 深人打交道的时候。本文不去照搬现成的各式调优建议,而试图通过对 JVM 的监控,结合使用 JSF 框架编写的测试项目,寻找内存泄漏问题的根源;通过使用一系列的工具来分析问题的细节,并最终尝试提供一些合理的、有效的改进建议和方法。

缘起

近日接到某同学告急消息,他的JSF(JSF2,下文都简称JSF)站点部署到线上之后,JVM内存占用一直上升,直到溢出。这让我颇感意外,接触JSF这么久,还真没好好注意过线上的性能问题,来的早不如来得巧,得嘞,就你了。

这是个比较典型的新闻性的站,类似虎嗅或36Kr这样的资讯站,PV量不多,但也不算少。整站是由JSF构建,页面打开速度尚可,这和站点部署在国内的云主机有一定关系。目前的情况是本地运行时,查看VM占用情况都比较正常;一旦部署上线,略有访问量之后,内存占用就飙升,直到内存耗尽,情况万分危急。

情景还原

正好我这里有一个JSF的小项目,本打算用来讲解JSF的事件原理和组件编写的(由于最近忙于移动应用而暂时搁置),不妨用来演示一下这个情况。首先来看看没有任何优化,一个简单的不能再简单的页面,关联一个ViewScope的BackingBean,

简单的JSF页面

图1. 简单的JSF页面

这里,我们将要用到几个工具,它们分别是VisualVM、SoapUI和Memory Analyzer。下图显示的是经过3次SoapUI的压测之后,在VisualVM里看到的堆情况。

经过3次压力测试之后的内存情况

图2. 经过3次压力测试之后的内存情况

图中A点是压测过后内存情况,B点是手工执行了一下GC。由此可以看出,在经历3次剧烈的波动之后,曲线整体是呈一个上扬的趋势,换句话说,内存占用是只升不降(注:这还是在手工执行了GC之后)。这就有点意思了,让人忍不住去探究探究。那么到底是什么原因导致内存只升不降呢?

堆分析

带着这样的疑问,我们来打开VisualVM的Profiler(这也是一个特别有用的功能点),看看究竟是谁才是罪魁祸首。

Profiler页面

图3. Profiler during 4th Load Test

Profiler页面2

图4. Profiler during 4th Load Test 2

图3 和图4 是第4次压测期间的Profiler情况,可以看到 char[] 是一颗耀眼明星,蓝框中的生存代数达到了惊人的37代,也就意味着,这货在GC执行了37次之后,还顽强的活着。

Profiler during 5th Load Test

图5. Profiler during 5th Load Test

图5 可以更加明显的看到, char[] 的存活代数已达到了惊人的 47 !也就说,内存回收对这货完全无用啊。当然,说完全无用是有点夸张,至少说明了有很多的 char[] 存活着。仔细的看图表,还可以看到,String 对象好像也很多,好像也是存活了 47 代,等等,好像有点什么发现了?String 为什么这个多?为什么没被回收?为什么和 char[] 一样活得久?一连串的问题浮现出来。

回到Java里来,String的背后存储是用的 char[],哦,既然这样,那也就是说,堆里面的老代中,存在了太多了的字符串无法回收,是这样么?带着这样的疑问,去做一个堆的dump。在这里,由于我是本地,就直接在“监视”标签页中执行dump就完了,如果是线上的服务器,可别这么搞呀。

话说,拿到了dump文件,用神器mat(Eclipse Memory Analyzer 简称 mat)打开它。

mat open wizard

图6. mat open wizard

向导我们直接选择“Leak Suspects Report”,恩,看来这个内存泄漏是的高发病、常见病嘛。

overview - mat

图7. overview – mat

哎呀呀,神器就是神器,刚刚打开dump文件,啥也没干呢,就看到这么个惊喜呀,红果果的告诉我谁是头号疑犯,恩,靠谱。等等,好像有点不对劲,刚刚在Profiler里明明得出结论是 String 太多回收不了,这里怎么是 org.apache.catalina.session.StandardSession 呢?好奇怪。究竟是什么情况?接着往下看,我们看一下Histogram好了。

Histogram - mat

图7. Histogram – mat

图7的堆dump文件显示了,在堆中占用排序后,排名靠前都基本都是和 HashMap、char[] 相关,好像有点端倪了,来来,继续。HashMap也好,StandardSession也好,这些都不直观,我们来看最直观的 char[]. 打开 char[]的 Object List,

objects of char[] - mat

图8. objects of char[] – mat

我们看到了一堆熟悉的字符串,有木有? “j_idt9″、”j_id1″这些是JSF为页面视图组件树上的组件自动生成的ID,图8 还可以看到,相同的字符串,存在很多份,并没有重用。

open Path To GC Roots -mat

图9. open Path To GC Roots -mat

随便选一个字符串,我们来看看它到 GC Root 的路径上有哪些对象。

Path to GC Roots - mat

图10. Path to GC Roots – mat

到目前为止,我们都在看图,没有涉及什么高深理论,实际上,这里需要补充一个理论:垃圾对象判定方法。常用的有两种,一种是所谓的引用计数法(Python在用),它简单易用易理解,缺点也很明显,无法解决对象相互引用而无法回收的问题。另外一种就是根路径搜索法(GC Roots Trace)。是在现在主流的程序语言中(Java、C#甚至古老的Lisp),均使用跟路径搜索算法(关于根路径搜索更加详细的内容可以参阅这里。另外更加深入、全面的讲解可以参看周志明的《深入理解Java虚拟机 JVM高级特性与最佳实践》 一书第三章)。

回到图10, 我们可以看到,我们选定一个字符串对象,到GC Root的路径上居然有10个对象,都是些什么呢?噢,我们看到了熟悉的东西:com.sun.faces.util.LRUMap .好家伙,果不其然,JSF脱不了干系啊。还有一个老熟人: StandardSession。种种迹象表明,这是由于JSF的缓存(LRUMap)了大量的字符串,而缓存对象本身又通过一条路径引用到了GC Root上来。这样一来,无论如何都无法被JVM标记为垃圾了,回收也就无从谈起。

读者朋友,你有想起来什么吗?对啦,我在本文开头的时候说过,测试页面是一个ViewScopedBackingBean,是不是?既然是 ViewScoped,也就是 Request 级别的生存周期,问题就来了,怎么会在Session里面缓存这么多东西呢?这是其一。其二,你不奇怪为什么会有这么多Session对象么?我的并发测试只是5个线程并发而已。为了解释这些疑问,追根溯源,下一篇将深入挖掘JSF的源代码,带您探寻JSF占用大量内存背后的原因,敬请期待。

(待续)

Happy new year!

Bill 2014-01-01

© 2022, Bill X.