zoukankan      html  css  js  c++  java
  • JVM Code Cache空间不足,导致服务性能变慢

    本文阅读时间大约5分钟。

    640?wx_fmt=jpeg

    有业务反馈,线上一个应用运行了一段时间之后,在高峰期之后,突然发现处理能力下降,接口的响应时间变长,但是看Cat上的GC数据,一切都很正常。

    通过跳板机上机器查看日志,发现一段平时很少见到的日志:

    Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled.	
    Java HotSpot(TM) 64-Bit Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize=.	
    ...	
    “CompilerThread0” java.lang.OutOfMemoryError: requested 2854248 bytes for Chunk::new. Out of swap space?

    其中CodeCache is full,说明Code Cache已经满了,导致Compiler失效,这是为什么?

    首先,我们得了解什么是Code Cache。

    什么是Code Cache

    Java代码在执行次数达到一个阈值会触发JIT编译,一旦代码块被编译成本地机器码,下次执行的时候会直接运行编译后的本地机器码。所以这本地机器码必须被缓存起来,而缓存这个本地机器码的内存区域就是Code Cache,它并不属于Java堆的一部分,除了JIT编译的代码之外,Java所使用的本地方法代码(JNI)也会存在codeCache中。

    Code Cache 调优

    由于Code Cache是一块内存区域,那么肯定有大小的限制,但是不同版本的JVM、不同的启动方式,Code Cache的默认大小也不同,可通过 jinfo-flagReservedCodeCacheSize 进行查看。

    服务启动之后,随着时间的推移,肯定会有越来越多的方法被JIT编译成本地机器码,并存放到Code Cache,由于Code Cache大小是固定的,那么就存在被用完的风险。

    一旦Code Cache被填满,就会出现下面情况:

    • JVM的JIT功能会被停止,将不会编译任何额外的代码。

    • 被编译过的代码仍然以编译方式执行,但是尚未被编译的代码只能以解释方式执行了。

    这种情况下,如果应用中还有很多代码以解释方式执行,其性能会大大降低。为了避免这种情况,就需要对Code Cache比较深入的理解。

    JVM启动的时候,Code Cache所需内存会被单独初始化,这时候Java堆还会被初始化,所以Code Cache和Java堆是两块独立内存区域。

    codeCache.cppCodeCache::initialize()方法中,实现了Code Cache的初始化

    640?wx_fmt=png

    Code Cache包含了3种数据:

    • NonNMethodCode

    • ProfiledCode

    • NonProfiledCode

    通过 SegmentedCodeCache参数可以选择按照整体初始化,还是分段初始化。

    通过 -XX:ReservedCodeCacheSize参数可以指定Code Cache的初始化大小,这个默认值在不同的JDK版本也不同,目前我这边调试的是OpenJDK11,默认大小是240M,这个已经够用了。

    可以看下其它版本的默认大小:

    640?wx_fmt=png

    对于那些只有32M、48M的就可能存在Code Cache不足的隐患,增加 ReservedCodeCacheSize可以是一个解决方案,但这通常只是一个临时的解决方案。

    幸运的是,JVM提供了一种比较激进的codeCache回收方式:Speculative flushing。

    在JDK1.7.0_4之后这种回收方式默认开启,而之前的版本需要通过一个参数来开启:-XX:+UseCodeCacheFlushing

    在Speculative flushing开启的情况下,当Code Cache不足时:

    • 最早被编译的一半方法将会被放到一个old列表中等待回收;

    • 在一定时间间隔内,如果old列表中方法没有被调用,这个方法就会被从Code Cache清除;

    很不幸的是,在JDK1.7中,Speculative flushing释放了一部分空间,但是从编译日志来看,JIT并没有恢复正常,并且系统整体性能下降很多,出现了大量超时。

    在Oracle官网上,有这样一个Bug:http://bugs.java.com/bugdatabase/viewbug.do?bugid=8006952

    由于算法问题,当Code Cache不足之后会导致编译线程无法继续,并且消耗大量CPU,导致系统运行变慢。640?wx_fmt=png

    这个bug在7u101及8以后的版本已经得到修复。

    640

    下方查看历史文章

    640?wx_fmt=png

    通过SOFA看Java服务端如何实现运行时的模块化

    JVM调优实战:G1中的to-space exhausted问题

    MAT入门到精通(一)

    MAT入门到精通(二)

    640?wx_fmt=gif

    号专注于后端技术、JVM问题排查和优化、Java面试题、个人成长和自我管理等主题,为读者提供一线开发者的工作和成长经验,期待你能在这里有所收获。

    640?wx_fmt=png

    640

  • 相关阅读:
    (十三)页面权限控制
    (十二)用户管理模块
    Vue笔记:生命周期和钩子函数
    (十一)第三方图标库
    (十)动态加载菜单
    windows下php配置环境变量
    docker在mac下安装及配置阿里云镜像加速
    pm2-web监控
    PHP判断两个矩形是否相交
    ubuntu下安装ffmpeg扩展
  • 原文地址:https://www.cnblogs.com/javaadu/p/11742572.html
Copyright © 2011-2022 走看看