jvm问题排查(代码片段)

关键词：

jetty的调用场景是：为了支持Servlet规范中的注解方式（使得不再需要在web.xml文件中进行Servlet的部署描述，简化开发流程），jetty在启动时会扫描class、lib包，将使用注解方式声明的Servlet、Listener注册到jetty容器，在扫描jar包的时候调用了inflate，分配了大量的内存，此时通过关键词搜索到Memory leak while scanning annotations，这篇文章给出了两种解决方法，一种是评论处所说，禁用缓存（说是jdk1.8的bug）：

Here’s a link to the java bugs database issue: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8156014

I’d like to be able to comment on it, but I can’t seem to find a link to allow me to do that.

The comments I’d like to add are:

the problem is still reproduceable as of jdk8u112

the problem seems to be fixed in jdk9: I tested jdk9ea+149 and couldn’t reproduce

I’ve tried some workarounds for jdk8: it seems the ServiceLoader impl uses the jarurlconnection caching, so it may be of some benefit to try to disable url caching (although not sure of the effects on performance).

Try creating an xml file (eg called “caches.xml”) with the following contents:

<Configure id="Server" class="org.eclipse.jetty.server.Server">

 <Set class="org.eclipse.jetty.util.resource.Resource" name="defaultUseCaches">false</Set> 
 <New class="java.io.File">
   <Arg>
    <SystemProperty name="java.io.tmpdir"/>
   </Arg>
   <Call name="toURI">
     <Call id="url" name="toURL">
       <Call name="openConnection">
         <Set name="defaultUseCaches">false</Set>
       </Call>
     </Call>
   </Call>
 </New>
</Configure>

尝试之后，java进程占用的物理内存由6.5G降到了5.9G，有一定的效果，但是我们估算的java进程应该占4.5G左右，还有1.4G内存被谁占用了呢？

再尝试另外一种方法：

We were investigating a Jetty application that used much more memory than it was supposed to do (near a Gb more than the max heap size plus the max metaspace size). We found out that the extra memory was Native memory, being allocated using malloc via some library (we don’t have native code in our app). Then we used jemalloc ( http://www.canonware.com/jemalloc/) to find out which class was doing this allocation and we found out that it was java.util.zip.Inflater. Via jstack we were able to find calls to the library and the main caller was Jetty, while in the process of looking for annotations. We disable annotations for the application and the memory usage went back to normal.

既然jetty调用是因为扫描jar包中的注解，我们应用中没有通过注解声明的Servlet、Listener，是不是可以不需要扫描这一步，故而在jetty.xml中将注解扫描的方式去掉：

<!-- <Item>org.eclipse.jetty.annotations.AnnotationConfiguration</Item> -->
<!-- Item>com.xxx.boot.RJRAnnotationConfiguration</Item> -->

再重启应用，发现内存使用由6.5G降到了3.9G，并且应用运行稳定后不再占用swap，

出处：

http://www.longtask.net/2018/11/15/swap-used-full/#top

jvm堆外内存排查详解(代码片段)

文章目录前言一、堆外内存排查1.背景2.内存对比3.堆外内存检查4.排查堆外内存结尾前言内存泄漏想必大家并不陌生，对于jvm的内存泄漏，有很多排查手段和方便的排查工具，例如MAL，但是对于非jvm的内存，如... 查看详情

jvm问题排查(代码片段)

jetty的调用场景是：为了支持Servlet规范中的注解方式（使得不再需要在web.xml文件中进行Servlet的部署描述，简化开发流程），jetty在启动时会扫描class、lib包，将使用注解方式声明的Servlet、Listener注册到jetty容器，在扫描jar包的时... 查看详情

jvm故障问题排查心得「内存诊断系列」jvm内存与kubernetes中pod的内存容器的内存不一致所引发的oomkilled问题总结（下）(代码片段)

承接上文之前文章根据《【JVM故障问题排查心得】「内存诊断系列」JVM内存与Kubernetes中pod的内存、容器的内存不一致所引发的OOMKilled问题总结（上）》我们知道了如何进行设置和控制对应的堆内存和容器内存的之间的关... 查看详情

jvm内存及cpu占用过高排查(代码片段)

问题排查方法方法一通过top命令查看当前CPU及内存情况top86786java98.413:22.7获得pid,通过top-H-p86786查看有问题的线程说明：-H指显示线程，-p是指定进程可以看到两个CPU或内存占用较高的线程，记下PID（此处的PID即为线... 查看详情

jvm技术专题内存问题分析和故障排查规划指南「实战篇」(代码片段)

...xff0c;其中pid为16494的进程一个应用占了28.7的内存定位线程问题使用ps查看16494的线程情况命令&# 查看详情

jvm技术专题网络问题分析和故障排查规划指南「实战篇」(代码片段)

前提概要涉及到网络层面的问题一般都比较复杂，场景多，定位难，成为了大多数开发的噩梦，应该是最复杂的了。这里会举一些例子，并从tcp层、应用层以及工具的使用等方面进行阐述。超时超时错误大部... 查看详情

jvm故障问题排查心得「线程诊断系列」通过jstack线程状态分析虚拟机线程问题指南(代码片段)

...力哦，因为它可以帮助我们在危急关头去解决和分析问题，接下来，就让我们开始分析和研究一下jstackdump文件吧。jstackDump日志文件中的线程状态dump文件里，值得关注的线程状态死锁，Deadlock（重点关注... 查看详情

jvm故障问题排查心得「内存优化技术」java虚拟机内存优化实战案例分析指南(代码片段)

问题总结内存多占1G左右，CPU利用率没有明显变化，但随着CMS收集抖动，最高达40%，CPUload平均高出1.0左右。几乎0停顿，相比于之前每隔5分钟应用停顿3-4s，调优后的应用几乎没有停顿时间，每次”stopthe... 查看详情

一篇文章搞清jvm死锁问题及排查

...讨：什么是死锁出现死锁的原因如何避免死锁代码中死锁问题怎么排查@目录1.什么是死锁2.出现死锁的原因3.如何预防和避免死锁4.实战JVM死锁问题排查4.1死锁代码案例4.2死锁问题JVM工具排查4.2.1jps+jstack方式排查4.2.2jconsole方式排... 查看详情

[转]jvm内存模型(代码片段)

最近排查一个线上java服务常驻内存异常高的问题，大概现象是：java堆Xmx配置了8G，但运行一段时间后常驻内存RES从5G逐渐增长到13G#补图#，导致机器开始swap从而服务整体变慢。由于Xmx只配置了8G但RES常驻内存达到了13G，多出了5G... 查看详情

记一次newarraylist导致的cpu飙升问题排查(代码片段)

...post/7139202066362138654前言当时场景正常的jvm监控曲线图产生问题的jvm监控曲线图具体分析结束语昨天线上容器突然cpu飙升，也是第一次排查这种问题所以记录一下~前言首先问题是这样的，周五正在写文档，突然收到了... 查看详情

记一次newarraylist导致的cpu飙升问题排查(代码片段)

...post/7139202066362138654前言当时场景正常的jvm监控曲线图产生问题的jvm监控曲线图具体分析结束语昨天线上容器突然cpu飙升，也是第一次排查这种问题所以记录一下~前言首先问题是这样的，周五正在写文档，突然收到了... 查看详情

jvm内存增长问题排查

jvm内存增长问题排查排查个jvm内存占用持续增加的问题，纪录一下，引以为戒。运维发现应用jvm内存占用在发布后回落，然后持续增高，，dump后分析一下： 占内存的大部分是这种名字相似的bean，哪里会产生这么多相同类产... 查看详情

jvm堆外内存排查详解(代码片段)

文章目录前言一、堆外内存排查1.背景2.内存对比3.堆外内存检查4.排查堆外内存结尾前言内存泄漏想必大家并不陌生，对于jvm的内存泄漏，有很多排查手段和方便的排查工具，例如MAL，但是对于非jvm的内存，如... 查看详情

java内存异常触发fgc无效导致cpu持续100%原因(线上jvm排查之三)(代码片段)

前言：提高Java性能需要避免FGC，尽量在YGC里解决问题，本文以一则线上真实的案例来分析因为内存过大导致YGC不了，甚至FGC都不行，导致CPU持续100%，以及这个中间年轻代，年老代的变化。本文给出一个重要的推论CPU持续100%意味... 查看详情

java内存异常触发fgc无效导致cpu持续100%原因(线上jvm排查之三)(代码片段)

前言：提高Java性能需要避免FGC，尽量在YGC里解决问题，本文以一则线上真实的案例来分析因为内存过大导致YGC不了，甚至FGC都不行，导致CPU持续100%，以及这个中间年轻代，年老代的变化。本文给出一个重要的推论CPU持续100%意味... 查看详情

jvm堆外内存排查详解(代码片段)

文章目录前言一、堆外内存排查1.背景2.内存对比3.堆外内存检查4.排查堆外内存5.glibc内存泄露结尾前言内存泄漏想必大家并不陌生，对于jvm的内存泄漏，有很多排查手段和方便的排查工具，例如MAL，但是对于非jvm... 查看详情

从排查一个登录问题看jvm类加载机制

问题来源这段时间我们在切换某海外环境的登录体系，遇到一个应用会话校验有问题，排查过程如下：从会话逻辑trace去看，走到了tair获取session的代码里，实例代码如下：publicclassSessionManagerProxyImplimplementsCnSessionManagerProxy{privatev... 查看详情