这篇文章主要介绍了java内存异常使用导致full gc频繁如何解决的相关知识，内容详细易懂，操作简单快捷，具有一定借鉴价值，相信大家阅读完这篇java内存异常使用导致full gc频繁如何解决文章都会有所收获，下面我们一起来看看吧。

创新互联公司专注为客户提供全方位的互联网综合服务，包含不限于成都网站制作、成都网站建设、花山网络推广、成都小程序开发、花山网络营销、花山企业策划、花山品牌公关、搜索引擎seo、人物专访、企业宣传片、企业代运营等，从售前售中售后，我们都将竭诚为您服务，您的肯定，是我们最大的嘉奖；创新互联公司为所有大学生创业者提供花山建站搭建服务，24小时服务热线：18980820575，官方网址：www.cdcxhl.com

问题系统

日常巡检发现，应用线上出现频繁full gc

现象

应用线上出现频繁full gc

排查过程

分析dump

拉dump文件：小插曲：dump时如果指定:live，则在dump前jvm会先进行一次full gc，并且gc log里会打印dump full gc，这种对非内存泄漏导致的线上异常内存情况排查反而会带来不便，导致我们多dump了好几次。

分析dump文件：

a. 发现大量long[]数组占用最大空间，有异常情况

b. 查看gc根节点，发现这些long[]数据大部分是被org.HdrHistogram.Histogram持有，每个Histogram对象会持有一个2048size的long[]

c. 查看Histogram实例的数量，竟然有5w个，对比下正常项目的堆栈，大约是100倍

d. 这里又有一个插曲，一开始习惯用mat分析，但是mat生成的报告对分析泄露比较有用，对于分析异常的内存没有jvisualvm.exe和idea的profiler好用

排查原因

本地启动，可以复现这个类的内存使用情况，于是本地起一个其他内存正常的服务与有问题的应用，分析内存对比

这里用的是idea的profiler，很方便

发现差异：

对比正常的应用，发现异常应用的引用存在异常的来自

● rx.internal.operators.OnSubscribeReduceSeed$ReduceSeedSubscriber的引用，怀疑就是这个异常引用就是导致这些实例无法在新生代回收而是堆积到了老年代触发full gc的原因

排查差异：

简单看了下相关代码，看不出个所以然，直接debug对比

系统确实走进了相关的代码，增加了对Histogram的引用，而正常应用没有

但是光这样也看不出来为什么，此时关注到了左下角的线程池，这个线程池比较奇怪，是Metric的线程池
Metric是Hystrix用来统计相关指标，来供自己的dashboard或者用户来获取，以此来了解系统熔断相关参数和指标的功能
再看堆栈，走到这里的逻辑是

这个流用来统计单位时间内的系统指标，导致Hystrix使用Histogram的long数组实现类似滑动窗口的效果统计单位时间内的指标
Histogram本身是Hystrix用来实现类似桶+滑动窗口的功能，来统计单位时间内的流量，但是因为开启了指标参数，导致hystrix为了统计更长时间范围内的指标，新增了对象持有更多（单位时间内）的Histogram引用来聚合，这部分引用因为是统计更长时间范围周期的，就会因为引用持有时间长而到老年代，但是本质并不是内存泄漏，所以每次full gc后又可以得到回收

解决问题

看到上面的差异和怪异的线程池，第一反应就是关闭metric使应用不走到这段逻辑中增加引用，看官方文档，该配置默认是打开的，并且确认该功能只影响指标统计不影响断路器本身功能，使用配置hystrix.metrics.enabled=false配置来关闭
新增配置后，验证并查看堆栈，引用恢复正常，并且系统在一段时间后并没有新增更多的Histogram实例，发布线上后观察一段时间，full gc问题确实得到解决

根本原因

在当时发现解决的办法并验证后，并没有时间去研究hystrix.metrics.enabled默认配置就是true但是其他应用没有出现这个full gc问题的原因， 先解决了之后后续再继续跟进排查根本原因防止其他项目也出现相同问题

之前发现可疑的线程池是HystrixMetricsPoller ，经过查看，该线程池由HystrixMetricsPollerConfiguration

类开启，主要依靠hystrix.metrics.enabled开启，但是默认是true，为什么其他项目没有开启呢？

搜了下源码，这个类的开启还和一个注解有关

对比了一下代码，果然只有异常的应用使用了这个注解，这个注解的目的是开启断路器

但是研究之后发现，不使用这个注解，熔断等功能依旧可用，原因是在spring-cloud高版本之后，spring通过使用hystrix封装openfeign的方法来使用熔断，而不是集成整个hystrix体系，可能spring-cloud也发现了hystrix内存使用上的问题

所以在较高版本（起码我们的版本），feign是通过feign.hystrix.enabled来开关断路器的（这个开关是关闭的话，单纯加@EnableCircuitBreaker注解断路器是不会生效的）

其实在更高点版本的spring-cloud中，@EnableCircuitBreaker这个注解已经被标注为废弃了，但是可能因为我们是中间版本，所以存在既没有标注废弃其实又没有什么用的情况

总而言之，feign的断路功能只通过feign.hystrix.enabled来控制，增加@EnableCircuitBreaker注解之后仅仅只是会开启Hystrix其他所有的指标等功能

关于“java内存异常使用导致full gc频繁如何解决”这篇文章的内容就介绍到这里，感谢各位的阅读！相信大家对“java内存异常使用导致full gc频繁如何解决”知识都有一定的了解，大家如果还想学习更多知识，欢迎关注创新互联行业资讯频道。

本文题目：java内存异常使用导致full gc频繁如何解决
网站路径：http://pwwzsj.com/article/pdjjig.html