JMAP

一、先查询到java进程 jps -l 二、分析jvm内存使用情况 jmap -heap 19570 三、分析创建对象数量 jmap -histo:live 19570 来源： oschina 链接： https://my.oschina.net/fellowtraveler/blog/4289686

JVM是java从业者，必须要迈过的坎，不管你是初级、中级还是高级，都是必须掌握的，而且在面试中，jvm也是必考题，如果你不深入了解话，那去面试找工作肯定是有点难受的。 本文将重点介绍面试过程中常见的 JVM 题目，将面试题分为三大类：基础题目，进阶题目，实战题目 。 基础 1.1 JDK、 JRE、JVM 的关系是什么？ 什么是 JVM ？ 英文名称 ( Java Virtual Machine )，就是 JAVA 虚拟机， 它只识别 .class 类型文件，它能够 将 class 文件中的字节码指令进行识别并调用操作系统向上的 API 完成动作。 什么是 JRE ？ 英文名称（ Java Runtime Environment ），Java 运行时环境。 它主要包含两个部分：JVM 的标准实现和 Java 的一些基本类库。相对于 JVM 来说，JRE多出 来一部分 Java 类库。 什么是 JDK？ 英文名称（ Java Development Kit ），Java 开发工具包。 JDK 是整个 Java 开发的核心，它集成了 JRE 和一些好用的小工具。 例如：javac.exe、java.exe、jar.exe 等。 这三者的关系：一层层的嵌套关系。JDK > JRE > JVM。 1.2 JVM 的内存模型以及分区情况和作用 如下图所示： 黄色部分为线程共有

告警 正在开会，突然钉钉告警声响个不停，同时市场人员反馈客户在投诉系统登不进了，报504错误。查看钉钉上的告警信息，几台业务服务器节点全部报CPU超过告警阈值，达100%。 赶紧从会上下来，SSH登录服务器，使用 top 命令查看，几个Java进程CPU占用达到180%，190%，这几个Java进程对应同一个业务服务的几个Pod（或容器）。 定位 使用 docker stats 命令查看本节点容器资源使用情况，对占用CPU很高的容器使用 docker exec -it <容器ID> bash 进入。 在容器内部执行 top 命令查看，定位到占用CPU高的进程ID，使用 top -Hp <进程ID> 定位到占用CPU高的线程ID。 使用 jstack <进程ID> > jstack.txt 将进程的线程栈打印输出。 退出容器， 使用 docker cp <容器ID>:/usr/local/tomcat/jstack.txt ./ 命令将jstack文件复制到宿主机，便于查看。获取到jstack信息后，赶紧重启服务让服务恢复可用。 将2中占用CPU高的线程ID使用 pringf '%x\n' <线程ID> 命令将线程ID转换为十六进制形式。假设线程ID为133，则得到十六进制85。在jstack.txt文件中定位到 nid=0x85 的位置，该位置即为占用CPU高线程的执行栈信息

　　今天面了个32岁的Java程序员，各方面都挺好，问啥都会，对于JVM调优问题，答得还行，最后问了个Go语言GC问题，就答不上来了，走时几乎落泪...唉！ 　　 细想想... 　　当面试官向你提问JVM的实战问题时，你是否感觉到无所适从？ 　　想解决生产环境中的GC问题，你是否感觉到狗咬刺猬，无处下嘴？ 　　面对JVM的海量参数，你是否感觉到迷茫无助？ 　　看过很多的JVM文章，但当遇到了生产环境中真实问题的时候，你是否依然不知道如何进行分析排查？ 　　如果是这样，我觉得我们大家先想清楚在 金九银十 这个时间段“ 自己想要什么 ”最为重要 　　 　　我认为是 “实战” ！ 　　 “实战” 可以让我们 快速消除痛点，解决面试，积累实战经验 。 　　在这里小编推荐你，拿出2小时的时间 　　赶紧参加【马士兵老师】的 「JVM实战调优」 集训营 　　马老师带你横扫一切关于JVM的面试问题，吊打所有敢于提问JVM的面试官。 　　让你在简历中，填写上JVM调优经历，为升职加薪添上浓墨重彩的一笔。 　　 点开看... 　　 　　 下面这些内容，全网首讲，你从未听过，且只讲一次 　　Go语言内存管理和Java的异同，Rust语言为什么不需要GC？ 　　Golang的内存管理和Jvm有何不同？ 　　Golang的gc算法和Jvm有何不同？ 　　Golang的内存调优应该如何做？ 　

部门新来了个架构师，BAT背景，住在三环，开宝马上班，有车位。 小伙话不多，但一旦说话斩钉截铁，带着无法撼动的自信。原因就是，有他着数亿高并发经验，每一秒钟的请求，都是其他企业运行一年也无法企及的。这就让人非常羡慕，毕竟他靠这个比我赚的钱要多。 俗话说，要想在公司不出事故，那就不要写代码。干活多了容易出事，一身轻松无人问津，这就是现实。 但有时候还是要看成果的。新来的研发领导不懂技术，但他懂技术指标，所以就统计大家交git的数量，如果git活动是一片绿色如A股，那就算过关了。 架构师思来想去，决定领一个 并发量最高的需求 ：统计接口的平均响应时间和启动以来的求数。 为什么说它的并发量高呢？这是因为，它是统计所有接口的，自然比每一个接口的请求量都要大。AOP代码一包，每个接口都得从他这里走一圈。 该我们的架构师上场了。代码如图。 架构师说，我的代码不需要做注释。所谓的注释，都是给垃圾代码用的。我深以为是，他明显是受到了 Netflix 公司的影响。 程序考虑到了高并发场景，使用了线程安全的 ConcurrentHashMap ，然后每次通过监控key取出相应的数据，然后在value上递增。这么简单的代码，确实不需要增加什么注释。 作为项目里 并发量最高 的代码，出于对高级架构师的信任，我们并不需要做什么代码review，也不需要做什么测试。大家都很忙，代码您呐，到线上遛一遛吧。

告警 正在开会，突然钉钉告警声响个不停，同时市场人员反馈客户在投诉系统登不进了，报504错误。查看钉钉上的告警信息，几台业务服务器节点全部报CPU超过告警阈值，达100%。 赶紧从会上下来，SSH登录服务器，使用 top 命令查看，几个Java进程CPU占用达到180%，190%，这几个Java进程对应同一个业务服务的几个Pod（或容器）。 定位 使用 docker stats 命令查看本节点容器资源使用情况，对占用CPU很高的容器使用 docker exec -it <容器ID> bash 进入。 在容器内部执行 top 命令查看，定位到占用CPU高的进程ID，使用 top -Hp <进程ID> 定位到占用CPU高的线程ID。 使用 jstack <进程ID> > jstack.txt 将进程的线程栈打印输出。 退出容器， 使用 docker cp <容器ID>:/usr/local/tomcat/jstack.txt ./ 命令将jstack文件复制到宿主机，便于查看。获取到jstack信息后，赶紧重启服务让服务恢复可用。 将2中占用CPU高的线程ID使用 pringf '%x\n' <线程ID> 命令将线程ID转换为十六进制形式。假设线程ID为133，则得到十六进制85。在jstack.txt文件中定位到 nid=0x85 的位置，该位置即为占用CPU高线程的执行栈信息

一、命令概述 jmap 用于生成堆 dump文件，查看堆内对象统计信息、classloader 信息、 finalizer 队列 Usage: jmap [option] <pid> (to connect to running process) jmap [option] <executable <core> (to connect to a core file) jmap [option] [server_id@]<remote server IP or hostname> (to connect to remote debug server) where <option> is one of: <none> to print same info as Solaris pmap -heap to print java heap summary -histo[:live] to print histogram of java object heap; if the "live" suboption is specified, only count live objects -clstats to print class loader statistics -finalizerinfo to print information on objects awaiting

前面看了jdk的几个查看jvm信息的命令，然后只看不动手，不用回头就忘记的干干净净了。还是实际使用一下，然后顺便结合着jvm的内存分区，再深层次的记录一下几个分区的名称、大小、gc器、等等。 首先，查看一个进程，筛选一个进程，就可以使用 jps -mvl ，m让他带上方法参数，v带上设置的jvm参数，l显示完整的运行main方法名称。 完了之后，就可以看到这个pid的好多信息了。但是这个看到的不全，还是有些虚拟机默认的参数是看不到的，这个时候已经拿到了pid，再使用 jinfo -flags pid ，就会显示这个pid的手动在脚本里面显示的设置的各种参数，再加上虚拟机自动设置的默认值的参数，看一个pid的jvm设置就更完全了。 然后，还打算看看这个pid的gc情况，就可以使用 jstat -gc 1s 100 意思就是1s执行一次，执行100次，连续的看内存的gc才能发现问题。 下面是 jinfo -flags pid的输出 * 命令：jinfo -flags 64363 * 输出： * Attaching to process ID 64363, please wait... * Debugger attached successfully. * Server compiler detected. * JVM version is 25.131-b11 * * Non

引言 作者：黄青石 链接： https://www.cnblogs.com/huangqingshi/p/13336648.html?utm_source=tuicool&utm_medium=referral 周末了，觉得我还有很多作业没有写，针对目前大家对OOM的类型不太熟悉，那么我们来总结一下各种OOM出现的情况以及解决方法。 　　我们把各种OOM的情况列出来，然后逐一进行代码编写复现和提供解决方法。 　　1. 堆溢出-java.lang.OutOfMemoryError: Java heap space。 　　2. 栈溢出-java.lang.OutOfMemorryError。 　　3. 栈溢出-java.lang.StackOverFlowError。 　　4. 元信息溢出-java.lang.OutOfMemoryError: Metaspace。 　　5. 直接内存溢出-java.lang.OutOfMemoryError: Direct buffer memory。 　　6. GC超限-java.lang.OutOfMemoryError: GC overhead limit exceeded。 　　 第一种 ，堆溢出异常，相信大家很常见。即堆内对象不能进行回收了，堆内存持续增大，这样达到了堆内存的最大值，数据满了，所以就出来了。我们直接放溢出的代码样例

摘要： java内存dump是jvm运行时内存的一份快照，利用它可以分析是否存在内存浪费，可以检查内存管理是否合理，当发生OOM的时候，可以找出问题的原因。那么dump文件的内容是什么样的呢？ JVM dump java内存dump是jvm运行时内存的一份快照，利用它可以分析是否存在内存浪费，可以检查内存管理是否合理，当发生OOM的时候，可以找出问题的原因。那么dump文件的内容是什么样的呢？我们一步一步来 获取JVM dump文件 获取dump文件的方式分为主动和被动 i.主动方式： 1.利用jmap，也是最常用的方式：jmap -dump:[live],format=b,file= 2.利用jcmd，jcmd GC.heap_dump 3.使用VisualVM，可以界面操作进行dump内存 4.通过JMX的方式 MBeanServer server = ManagementFactory.getPlatformMBeanServer(); HotSpotDiagnosticMXBean mxBean = ManagementFactory.newPlatformMXBeanProxy(server, "com.sun.management:type=HotSpotDiagnostic", HotSpotDiagnosticMXBean.class); mxBean