JMAP

不,是GC。 gc永远会是 Java 程序员需要考虑的不稳定因素之一。 对JVM内存的系统级的调优主要的目的是减少GC的频率和Full GC的次数。 而GC的情景复杂又复杂，为了能更深刻的了解内存模型，参考《深入java虚拟机理解》，不定期更新JVM入门。 我自己遇到过一次内存泄漏，但不是线上环境，本地环境出现过一次，后来重新推包解决了，没有复现，那么平时的自用 服务器突然内存与磁盘IO暴增，你会如何调优？定位到具体线程后，是因为大对象占用空间造成，还是程序死循环了你如何解决？，关于JVM入门，以及JVM调优整理了地址请转至 https: //kkget .github.io/ 2020 /09/ 24 /JVM调优相关 https: //kkget .github.io/ 2020 / 10 / 13 /JVM从入门到放弃 以上内容不定期更新，今天主要从性能监控工具以及整理关于调优相关部分。 虚拟机性能监控工具 1.jps(JVM Porcess Status Tool) 功能：列出正在运行的虚拟机程序并显示执行主类名称以及进程ID( LVMID ,Local Virtiual Machine Identifier)。 jps -l 输出主类的全类名 jps -v 输出虚拟机启动时的JVM参数 格式 jps [ options ] [ hostid ] [root @zhaokk

不知道你有没有过这样的经历，经常在面试的时候被问到 JDK 相关的命令，如何排查线上的问题，线上程序突然崩了要怎么处理，等等类似这种场景。其实并不是每个开发人员都能有这种实战经验，现实工作中往往很多开发人员是接触不到线上环境的。但是作为一个以 Java 谋生的程序员，如果连这些 JDK 自带的一些命令都不知道，那也说不过去。 阿粉以前也是这样，从来没有接触过线上环境，有任何问题都是运维人员去处理，因为相关制度不允许开发人员接触生产服务器。但是作为一个有梦想的开发人员，不能接触不代表就不用学，阿粉还是私下好好学习了一波，万一哪天就用上了呢。 JDK 常用命令 先给大家看一张总览图，然后我们一个个命令去使用一下，感受一下。 JPS 说明：首先通过上图，我们看到使用 jps 或者 jps | grep -v Jps 命令的时候是可以找到当前系统所有JVM。上面第二条命令是过滤本身的 Jps 程序。可以看到，输入这个命令后，会展示出当前系统所有的 Java 程序，并且会输出进程号 pid（也就是前面的数字）。 我们通过命令 man jps 简单的看下说明，如下： 可以看到 jps 命令有五个参数，每个参数的含义如下， -q: 不输出类名信息和参数，只输出进程号 -m:展示输入到 main 方法的参数 -l:展示 main class 全路径 -v:展示输入 JVM 的参数 -V:不输出路径

来自：http://longtask.com/review/2014/06/07/java-permgen-outofmemory/ 工作以来，第三次出现内存溢出，第一次是ThreadLocal没有remove造成的问题；第二次是ExecutorService没有正确的shutdown造成的问题；这一次的问题在我出手排查之前，已经知道了是permgen在不断的增长，在permgen中主要有Class和Meta信息，常量。 在开始阶段：排除了ThreadLocal可能导致的问题；排除了Thread可能导致的问题；后面就需要从新的突破点找问题了。 1：基本设置的排查 查找日志中访问量较大的请求的URL： awk '{print $6}' service-digest.* |awk -F"," '{print $1 ",""1"}'|awk -F"," '{a[$1]+=$2;b[$1]++}END{for(n in a)print a[n] " " n }'|sort -n 查找日志中的调用很多的内容；依然没有发现问题；采用webbench一个个的调用请求来模拟操作，前十名的URL没有发现问题，后面的就没有查看了。 通过线下操作，发现也不是开始怀疑的RMI远程调用的问题； 针对CMS-GC，网上建议开通 -XX:+CMSClassUnloadingEnabled -XX:

目录 第一部分 走进Java 一、走进Java 第二部分 自动内存管理机制 二、内存区域和内存溢出异常 1、运行时数据区 2、HotSpot虚拟机对象探秘 3、OutOfMemoryError异常 三、垃圾收集器和内存分配策略 1、对象已死吗？如何确定对象是否还“活着” 2、垃圾回收算法 3、HotSpot算法实现 4、垃圾收集器 5、内存分配和回收策略 四、虚拟机性能监控与故障处理工具 1、jps 2、jstat。监视JVM内存工具。 3、jinfo。查看和修改JVM运行参数 4、jmap。命令用于生成heap dump文件 5、jstack。Java堆栈跟踪工具 五、常见JVM配置说明 1、JVM配置 1.3、参数说明 G1最佳实践 1、不断调优暂停时间指标 2、不要设置新生代和老年代的大小 3、关注Evacuation Failure 1、Minor GC、Major GC和Full GC之间的区别 2、常用命令 3、问题排查 七、虚拟机类加载机制 1、虚拟机把表示类的class文件加载到内存，经过校验、转换解析、初始化，最终形成可以被虚拟机直接使用的java类型，这就是虚拟机的类加载机制 2、类加载的时机 3、类加载的过程 4、类加载器 第五部分 高效并发 十二、Java内存模型与线程 1、硬件的效率与一致性 2、Java内存模型 3、Java与线程 十三、线程安全与锁优化

告警 正在开会，突然钉钉告警声响个不停，同时市场人员反馈客户在投诉系统登不进了，报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信息后，赶紧重启服务让服务恢复可用。 5.将2中占用CPU高的线程ID使用 pringf '%x\n' <线程ID> 命令将线程ID转换为十六进制形式。假设线程ID为133，则得到十六进制85。在jstack.txt文件中定位到 nid=0x85的位置，该位置即为占用CPU高线程的执行栈信息

是否你听说过JDK8之后HashMap已经解决的扩容死循环的问题，虽然HashMap依然说线程不安全，但是不会造成服务器load飙升的问题。 然而事实并非如此。少年可曾了解一种红黑树成环的场景，=v= 今日，在查看监控时候发现，某一台机器load飙升 感觉问题不对劲，ssh大法登陆机器，top，top -Hp,jstack，jmap四连击保存下来堆栈，cpu使用最高的线程，内存信息准备分析。 首先查看使用最耗费cpu的线程堆栈信息 cat stack | grep -i 34670 -C10 --color 我勒个去，HashMap，猜测八成死循环了，但是我们使用的JDK8，在8中通过栈封闭的链表替换，解决了扩容死循环的问题。疑惑，继续往下看。 根据堆栈信息，root方法是问题所在，点开HashMap源码 好嘛，load飙高，代码有个for语句，我觉得铁定死循环了，看代码情况只可能是两个红黑树节点的父亲节点相互引用才可以导致无法走出这个for语句。 然而这都是我的猜测，我没有证据。而且让我追红黑树的代码，也是需要耗费大量时间的事情，我需要快速验证我的猜测。 我之前dump下来了堆内存信息，我通过jhat 命令生成html的内存信息页面 然后输入http://localhost:7000查看。 我先找业务代码中持有这个HashMap的对象，然后点进去查询内部信息

　　线上故障主要会包括cpu、磁盘、内存以及网络问题，大多数故障可能会包含不止一个层面的问题，进行排查时候尽量四个方面依次排查一遍。例如 jstack、jmap 等工具，出问题就是df、free、top 三连，然后依次jstack、jmap，具体问题具体分析。 CPU: 　　一般来讲我们首先会排查 CPU 方面的问题。CPU 异常往往还是比较好定位的。原因包括业务逻辑问题(死循环)、频繁gc以及上下文切换过多。而最常见的往往是业务逻辑(或者框架逻辑)导致的，可以使用jstack来分析对应的堆栈情况。 　　使用 jstack 分析 CPU 问题 　　我们先用 ps 命令找到对应进程的pid(如果你有好几个目标进程，可以先用top看一下哪个占用比较高)。接着用 top -H -p pid 来找到 CPU 使用率比较高的一些线程 　　　　　　 　　然后将占用最高的 pid 转换为 16 进制 printf '%x\n' pid 得到 nid 　　接着直接在 jstack 中找到相应的堆栈信息 jstack pid |grep 'nid' -C5 –color 　　　　　　 　　可以看到我们已经找到了 nid 为 0x42 的堆栈信息，接着只要仔细分析一番即可。 　　当然更常见的是我们对整个 jstack 文件进行分析，通常我们会比较关注 WAITING 和 TIMED_WAITING

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

JAVA内存泄露分析和解决方案及WINDOWS自带查看工具 Java内存泄漏是每个Java程序员都会遇到的问题,程序在本地运行一切正常,可是布署到远端就会出现内存无限制的增长,最后系统瘫痪,那么如何最快最好的检测程序的稳定性,防止系统崩盘,作者用自已的亲身经历与各位分享解决这些问题的办法. 作为Internet最流行的编程语言之一,Java现正非常流行.我们的网络应用程序就主要采用Java语言开发,大体上分为客户端、服务器和数据库三个层次.在进入测试过程中,我们发现有一个程序模块系统内存和CPU资源消耗急剧增加,持续增长到出现java.lang.OutOfMemoryError为止.经过分析Java内存泄漏是破坏系统的主要因素.这里与大家分享我们在开发过程中遇到的Java内存泄漏的检测和处理解决过程. 一. Java是如何管理内存 为了判断Java中是否有内存泄露,我们首先必须了解Java是如何管理内存的.Java的内存管理就是对象的分配和释放问题.在Java中,内存的分配是由程序完成的,而内存的释放是由垃圾收集器(Garbage Collection,GC)完成的,程序员不需要通过调用函数来释放内存,但它只能回收无用并且不再被其它对象引用的那些对象所占用的空间. Java的内存垃圾回收机制是从程序的主要运行对象开始检查引用链,当遍历一遍后发现没有被引用的孤立对象就作为垃圾回收

工作之余，想总结一下JVM相关知识。 Java运行时数据区： Java虚拟机在执行Java程序的过程中会将其管理的内存划分为若干个不同的数据区域，这些区域有各自的用途、创建和销毁的时间，有些区域随虚拟机进程的启动而存在，有些区域则是依赖用户线程的启动和结束来建立和销毁。Java虚拟机所管理的内存包括以下几个运行时数据区域，如图： 1、程序计数器：指向当前线程正在执行的字节码指令。线程私有的。 2、虚拟机栈：虚拟机栈是Java执行方法的内存模型。每个方法被执行的时候，都会创建一个栈帧，把栈帧压人栈，当方法正常返回或者抛出未捕获的异常时，栈帧就会出栈。 （1）栈帧：栈帧存储方法的相关信息，包含局部变量数表、返回值、操作数栈、动态链接 a、局部变量表：包含了方法执行过程中的所有变量。局部变量数组所需要的空间在编译期间完成分配，在方法运行期间不会改变局部变量数组的大小。 b、返回值：如果有返回值的话，压入调用者栈帧中的操作数栈中，并且把PC的值指向 方法调用指令 后面的一条指令地址。 c、操作数栈：操作变量的内存模型。操作数栈的最大深度在编译的时候已经确定（写入方法区code属性的max_stacks项中）。操作数栈的的元素可以是任意Java类型，包括long和double，32位数据占用栈空间为1，64位数据占用2。方法刚开始执行的时候，栈是空的，当方法执行过程中