1 背景

java8的正式版本已经发布了2年多了，我们都知道java8更加高效，比如更加高效的G1、更加高效的jit、默认开启TieredCompilation更加高效的工作模式以及和“java.lang.OutOfMemoryError: PermGen space” 撒油啦啦 等等高大上的性能优化;当然了，这都不是最主要的：

主要原因是因为前一段时间线上tomcat很诡异的就突然挂掉了，经查失败log，是命中了一个jvm crash的bug，bug详见：#/view_bug.do?bug_id=8021898，jdk的1.7.0_60后修复了这个问题，正好看到java8那么多高大上的优化后，就准备一步到位直接升级到java8;

但是理想是美好的，现实是骨感的;我们很荣幸的掉进了坑里了，下面java培训机构主要从spring4.0的坑和新metaspace问题 这2个方面来描述。

2 spring4.0的问题

2.1 前言

上面说了，遇到了jvm的crash的bug，必须要升级jdk的版本;找了套测试环境做了回归，发现没啥问题，非常高兴，准备在线上开搞。

2.2 现象

最开始的找了2组流量相对较小的机器，升级后重启服务没有发现异常现象，以为没啥问题了，就准备开始搞一组qps比较高的机器，替换jdk重启之后没啥问题，然后观察了会，发现load在缓慢上升，紧接着服务的接口开始大量的超时，见下图：

2.3 排查过程

2.3.1 stack排查

首先，是抓了几个tomcat栈log下来,研究栈发现有大量的lock，见下图：

往下继续找正在运行的那个线程，如下图：

通过上面的现象看到，不管是lock的，还是runnable的，都是卡在的spring的代码栈下，这里就有点奇怪了，spring的版本没有升级啊，先否决了，因为java8针对gc和jit有过相关的，首先来开始排查这2者，继续往下;

2.3.2 排查gc

首先排查了gc的问题，发现除了比之前更频繁一点之外，其它没啥区别，也没有触发full gc，基本可以排除。

2.3.3 jit排查

java8针对jit有一些默认的优化，所以发现gc没有问题的情况下，首先想到的就是jit的设置问题。

首先怀疑的是jit的cache的内存大小问题，调大后重启，发现只能延缓一点load升高的时间，没有根本解决问题

然后是调整jit的默认线程数，之前我们是设置了2个线程，使用默认的3个线程，有一定的效果，抗住了20分钟;然后继续调大4、5，发现反而比之前挂了还要快，重启之后基本上就挂了，也基本可以排除。

2.3.4 spring排查

最容易出现问题的方面排查过了，没有发现问题，那就回归栈日志来排查，找不到明显问题，问下Google吧。

还真有发现：spring官网有人汇报过一个bug，SerializableTypeWrapper从jdk的1.7.0_51这个版本开始出现了性能瓶颈，bug地址详见：

#/browse/SPR-11335

我们之前的是用的jdk1.7.0_45这个版本，没有发现这个问题;具体原因在后面来描述。

2.4 解决方案

升级spring的版本就可以解决这个问题。

从4.0.3开始，spring针对jdk8有较大的改善，具体可参见官网说明：#/blog/2014/03/27/spring-framework-4-0-3-released-with-java-8-support-now-production-ready

2.5 问题分析

2..5.1 ResolvableType

首先我们来看下ResolvableType这个类的相关代码，如下图：

可以看到1018-1022行之间，先是从cache中取，如果没有取到，就会往cache中put一个，通过上面的栈可以知道，equals比较耗时(会通过SerializableTypeWrapper生成相关代理)，这里get和put之间没有任何拦截措施，get不到直接put，put内部是有lock的，就是我们看到的上面的lock的图，这样就有可能导致大量的线程等待。

按理说即使会慢，也应该只是在刚开始启动的时候，等都初始化完全后，cache中就有了，后面就好了啊，咱们继续往下看。

2.5.2 ConcurrentReferenceHashMap的问题

ConcurrentReferenceHashMap是一个soft cache, 过期的时候会走到put里，加锁等待，导致更多的线程block, 线程block导致tomcat更多的线程同时运行导致gc压力，而soft cache是一个软cache，压力过大时会被gc回收掉，这样会导致soft cache 接连失效;这也就验证了上面开始的gc比之间频繁的问题,这种情况在qps高的服务下会比较容易出现。

2.6 spring的修复方案

2.6.1 ResolvableType

可以看到在get之前加了一个check操作;大体意思就是checker一下cache的有效性，如果cache已过期，把过期的信息强制剔除以提高效率。

2.6.2 SerializableTypeWrapper

可以看到针对equals有优化操作;大体意思是在执行equals方法的时候，直接执行原始的equals，不用再经过多层代理的过滤;尤其是针对ResolvableType这种高执行频率的操作效果较好。

2.7 Metaspace的问题

2.7.1 前言

经过上面的折腾，终于算是把java8用上了，运行了几天之后很正常(其实是我想多了)。

2.7.2 现象

在大概一个星期之后的凌晨，突然收到报警，线上服务swap有报警或者服务挂掉了……

2.7.3 问题排查

查了下原因，问题出现在java8新搞得MetaSpace身上。

2.7.4 概念

首先来介绍2个概念：

2.7.4.1 PermGen

PermGen space的全称是Permanent Generation space,是指内存的永久保存区域，说说为什么会内存益出：这一部分用于存放Class和Meta的信息,Class在被 Load的时候被放入PermGen space区域，它和和存放Instance的Heap区域不同,所以如果你的APP会LOAD很多CLASS的话,就很可能出现PermGen space错误。这种错误常见在web服务器对JSP进行pre compile的时候。

2.7.4.2 MetaSpace

Java8将移除永久区，使用本地内存来存储类元数据信息并称之为：元空间(Metaspace)。

Java8的启动参数：PermSize 和 MaxPermSize 会被忽略并给出警告(如果在启用时设置了这两个参数)。

这意味着不会再有java.lang.OutOfMemoryError: PermGen问题，也不再需要你进行调优及监控内存空间的使用……但请等等，这么说还为时过早。在默认情况下，这些改变是透明的，接下来我们的展示将使你知道仍然要关注类元数据内存的占用。请一定要牢记，这个新特性也不能神奇地消除类和类加载器导致的内存泄漏。

2.7.5 Metaspace 容量

默认情况下，类元数据只受可用的本地内存限制(容量取决于是32位或是64位操作系统的可用虚拟内存大小)。

新参数(MaxMetaspaceSize)用于限制本地内存分配给类元数据的大小。如果没有指定这个参数，元空间会在运行时根据需要动态调整。

2.7.6 原因分析

在java8里，由于PermSize 和 MaxPermSize已经失效，而你又正好没有设置MetaspaceSize和MaxMetaspaceSize这2个参数，那么就有可能会导致 metaspace的空间在不停的扩展，会导致机器的内存不足;进而可能出现swap内存被吃;严重可能导致进程直接被系统直接kill掉。

3 总结

升级java8应该注意以下2点：

需配合Spring 4.0.3以上版本使用

需要配置Metaspace大小

暂时为止，升级java8的问题暂时告一段落。

如果你近期有升级java8的计划，正好你也看到了这篇文章，那么恭喜你，你可以少踩2个坑;java8很美好，升级需谨慎。