起因
表面现象：客户生产环境，运行一段时间(10~20天)后，无奈连贯kafka服务，这个景象重复呈现。
通过pinpoint监控查看故障前后的jvm状态，意外发现一个以前从未注意过的问题：那就是非堆内存满了。
从上图能够看进去，非堆内存满了之后，零碎进行了频繁的FullGC，然而内存并没有失去回收。
借助pinpoint，咱们往前回溯从上次jvm启动后，非堆内存的变动，发现：
- 9月2日，重启后， 非堆内存占用：300M
- 9月9日 1.4G
- 9月16日 2.1G
- 9月23日 3G
- 9月29日 4G
个别状况下，对于内存，咱们会比拟关注 堆内存，个别的内存透露，也都产生在堆内存中。非堆内存个别出问题的很少，所以咱们关注也比拟少。
初步狐疑
印象中，非堆内存(或者metaspace)存储的内容包含：class对象、字符串常量池、java栈内存、本地native库调配的内存、DirectByteBuffer调配的内存；
(下面形容可能不精确)
因为零碎中很少应用DirectByteBuffer，所以首先狐疑嵌入jvm过程的本地native库rocksdb，作为小文件读写缓存，rocksdb嫌疑最大。
于是咱们写了一个小程序对rocksdb的内存占用进行剖析，试验场景：10G数据写入rocksdb和随机读写，非堆内存始终稳固在 300M，并没有增长。于是排除了rocksdb的嫌疑。
发现问题
在排除rocksdb的嫌疑后，再回想到最后查看系统日志时的内存溢出提醒：CallWebService：java.lang.OutOfMemoryError: Compressed class space，网上搜寻一番，找到一篇知乎小短文：
JVM调优中，压缩类空间(Compressed Class space)如何了解
看到上面阐明：
一般来说，均匀一个 Klass 大小能够当成 1K 来算，默认的 1G 大小能够存储 100 万的 Klass。如果遇到了 `java.lang.OutOfMemoryError: Compressed class space`，就是类太多了，须要联合具体情况去抉择 JVM 调优还是 bug 排查。因为业务零碎失常启动状况下 class 大概是 3万个，这个溢出阐明零碎的class 靠近 100万了?
零碎呈现问题时，因为各种谬误较多，所以竟然疏忽了这个重要的错误信息，这也算是走了一段弯路。
联合出错地位：CallWebService，因为零碎中应用了CXF来动静调用webservice，动静调用webservice的过程蕴含了：java代码生成、class编译和加载的过程，
难道是这个过程存在class透露吗?
立刻开始口头，找到零碎应用的CXF版本：2.7.3，编写一个小程序来验证：
public static void main(String[] args) throws Exception { String wsdlUrl = "http://10.1.28.143:8094/services/test?wsdl"; String method = "AAAA"; Object[] params = { "1" }; for (int i = 0; i < 1000; i++) { Object[] result = invokeWebService(wsdlUrl, method, params); System.out.println(Arrays.asList(result)); } new CountDownLatch(1).await();}public static Object[] invokeWebService(String wsdlUrl, String method, Object... params) throws Exception { Client client = null; try { DynamicClientFactory factory = DynamicClientFactory.newInstance(); client = factory.createClient(wsdlUrl); return client.invoke(method, params); } finally { if (client != null) { client.destroy(); } }}应用jconsole察看调用过程，果然class数量在一直增长，FullGC也不能回收。
第一次解决
就CXF2.7.3动静调用webservice可能存在class透露问题，在网上检索一番，如同没看到有相干的话题。
去maven核心仓库search.maven.org查找CXF的最新版本，如下：
<dependency> <groupId>org.apache.cxf</groupId> <artifactId>cxf-bundle-compatible</artifactId> <version>3.5.3</version> <type>bundle</type></dependency>换上新版本再次试验，后果调用失常了。区别是 3.5.3版本Client对象提供一个close办法(2.7.3没有close办法)
public static Object[] invokeWebService(String wsdlUrl, String method, Object... params) throws Exception { Client client = null; try { DynamicClientFactory factory = DynamicClientFactory.newInstance(); client = factory.createClient(wsdlUrl); return client.invoke(method, params); } finally { if (client != null) { // client.destroy(); 2.7.3版本应用destroy办法 client.close(); // 3.5.3版本应用close办法 } }}查看 CXF3.5.3版本close办法的内容：
static class DynamicClientImpl extends ClientImpl implements AutoCloseable { final ClassLoader cl; final ClassLoader orig; DynamicClientImpl(Bus bus, Service svc, QName port, EndpointImplFactory endpointImplFactory, ClassLoader l) { super(bus, svc, port, endpointImplFactory); cl = l; orig = Thread.currentThread().getContextClassLoader(); //保留原始的classloader } @Override public void close() throws Exception { destroy(); if (Thread.currentThread().getContextClassLoader() == cl) { Thread.currentThread().setContextClassLoader(orig); //还原原始的classloader } }}原来，在创立DynamicClientImpl实例时保留了以后的上下文classloader，同时在close()时，对上下文classloader进行了还原。
咱们再一步跟踪下org.apache.cxf.endpoint.dynamic.DynamicClientFactory.createClient()的逻辑：
public Client createClient(String wsdlUrl, QName service, ClassLoader classLoader, QName port, List<String> bindingFiles) { //为了演示不便，上面只摘抄了要害代码 //0、实例化clientimpl对象 ClientImpl client = new ClientImpl(bus, svc, port, getEndpointImplFactory()); //1、依据wsdl生成java代码 JCodeModel codeModel = intermediateModel.generateCode(null, elForRun); File src = new File(tmpdir, stem + "-src"); Object writer = JAXBUtils.createFileCodeWriter(src); codeModel.build(writer); //2、编译java代码 File classes = new File(tmpdir, stem + "-classes"); setupClasspath(classPath, classLoader); List<File> srcFiles = FileUtils.getFilesRecurse(src, ".+\\.java$"); compileJavaSrc(classPath.toString(), srcFiles, classes.toString())); //3、创立classloader URL[] urls = new URL[] { classes.toURI().toURL() }; ClassLoader cl = ClassLoaderUtils.getURLClassLoader(urls, classLoader); //4、加载class JAXBContext context = JAXBContext.newInstance(packageList, cl, contextProperties); JAXBDataBinding databinding = new JAXBDataBinding(); databinding.setContext(context); svc.setDataBinding(databinding); //5、将新的classloader设置到以后线程上下文中，这一步的目标，是在后续应用invoke办法调用webservice时，能从以后线程上下文classloader中找到webservice动静生成的类 ClassLoaderUtils.setThreadContextClassloader(cl); //6、TypeClass初始化 (这一步含意还不分明) ServiceInfo svcfo = client.getEndpoint().getEndpointInfo().getService(); TypeClassInitializer visitor = new TypeClassInitializer(svcfo, intermediateModel, allowWrapperOps()); visitor.walk(); return client;}至此，class透露的起因应该比较清楚了：
起因是 CXF2.7.3在client.destroy()后， 短少上下文ClassLoader的还原，导致以后的ClassLoader变成了一个链，每动静调用一次，ClassLoader链就变长一次，导致所有加载的class都无奈卸载。因为降级CXF波及工作量较大，咱们只需在CXF2.7.3之上，在调用client前后加上一段小小的逻辑，来手工还原classloader就行了。革新如下：
public static Object[] invokeWebService(String wsdlUrl, String method, Object... params) throws Exception { Client client = null; ClassLoader orig = Thread.currentThread().getContextClassLoader(); try { DynamicClientFactory factory = DynamicClientFactory.newInstance(); client = factory.createClient(wsdlUrl); return client.invoke(method, params); } finally { if (orig != Thread.currentThread().getContextClassLoader()) { Thread.currentThread().setContextClassLoader(orig); //为2.7.3版本手工还原classloader } if (client != null) { client.destroy(); //2.7.3版本的用法 } }}再次实测成果如下：
问题至此，看上去仿佛完满解决了。但殊不知，前面还有一个微小的坑在等着咱们。
文章太长了，后续接着写。(给一点小提示，看文章题目)