VisualVM

总结步骤： 1，使用命令top -p <pid> ，显示你的java进程的内存情况，pid是你的java进程号，比如123 2，按H，获取每个线程的内存情况 3，找到内存和cpu占用最高的线程pid，比如15248 4，执行 printf 0x%x 15248 得到 0x3b90 ,此为线程id的十六进制 5，执行 jstack <pid进程>|grep -A 10 <转换的16进制线程Id>，得到线程堆栈信息中3b90这个线程所在行的后面10行 6，查看对应的堆栈信息找出可能存在问题的代码。 查看线程内存： top -H -p pid ,另一种方法通过pstree pid查到pid下所有的thread 然后top查看，按下H找到对应的线程即可。 1 故障现象 这天上午，有同事反映公司后台管理系统运行缓慢，运维同事检查发现cpu占用过高，重启服务器后故障消失。 这天下午，有同事也反映后台系统的某模块系统，运行缓慢，多次重启后故障仍然存在，使用top命令查看服务器的情况，发现cpu占用率接近100%。 2 cpu问题定位 定位问题进程 使用了top指令查看资源占用情况，发现PID为11705的进程消耗了大量的CPU资源，达到了780.4 定位问题线程 使用 ps -mp 11705 -o THREAD,tid,time 指令把该11705进程的thread,tid,time给列出来，

《深入理解 Java 虚拟机》笔记整理 正文 一、Java 内存区域与内存溢出异常 1、运行时数据区域 程序计数器：当前线程所执行的字节码的行号指示器。线程私有。 Java 虚拟机栈：Java 方法执行的内存模型。线程私有。 本地方法栈：Native 方法执行的内存模型。线程私有。 Java 堆：存放对象实例。分为新生代（Eden 空间、From Survivor 空间、To Survivor 空间）和老年代。线程共享。 方法区：存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。也称为“永久代”。线程共享。 运行时常量池：方法区的一部分，用于存放编译期生成的各种字面量和符号引用。 线程共享。 直接内存。 2、对象的创建 类加载检查 -> 分配内存 -> 初始化零值 -> 设置对象头 -> 执行 init 方法。 类加载检查：检查 new 指令的参数能否在常量池中定位到一个类的符号引用，以及这个符号引用代表的类是否已被加载、解析和初始化过。 分配内存：把一块确定大小的内存从 Java 堆中划分出来。 初始化零值：将分配到的内存空间初始化为零值（不包括对象头）。 设置对象头：虚拟机需要对对象进行必要的设置，这些信息存放在对象的对象头中。 执行 init 方法：把对象按照程序员的意愿进行初始化。 3、对象的内存布局 对象头： Mark Word

【推荐阅读】微服务还能火多久？>>> 正文 一、Java 内存区域与内存溢出异常 1、运行时数据区域 程序计数器 ：当前线程所执行的字节码的行号指示器。线程私有。 Java 虚拟机栈 ：Java 方法执行的内存模型。线程私有。 本地方法栈 ：Native 方法执行的内存模型。线程私有。 Java 堆 ：存放对象实例。分为新生代（Eden 空间、From Survivor 空间、To Survivor 空间）和老年代。线程共享。 方法区 ：存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。也称为“永久代”。线程共享。 运行时常量池 ：方法区的一部分，用于存放编译期生成的各种字面量和符号引用。 线程共享。 直接内存 。 2、对象的创建 类加载检查 -> 分配内存 -> 初始化零值 -> 设置对象头 -> 执行 init 方法。 类加载检查 ：检查 new 指令的参数能否在常量池中定位到一个类的符号引用，以及这个符号引用代表的类是否已被加载、解析和初始化过。 分配内存 ：把一块确定大小的内存从 Java 堆中划分出来。 初始化零值 ：将分配到的内存空间初始化为零值（不包括对象头）。 设置对象头 ：虚拟机需要对对象进行必要的设置，这些信息存放在对象的对象头中。 执行 init 方法 ：把对象按照程序员的意愿进行初始化。 3、对象的内存布局 对象头 ： Mark

【推荐阅读】微服务还能火多久？>>> 问题描述 最近公司的线上监控系统给我推送了一些kafka lag持续增长的消息，我上生产环境去看了相应的consumer的情况，发现几台机器虽然还在处理消息，但是速度明显慢了很多。 问题猜测与验证 我猜测是JVM频繁做Full GC，导致进程也跟着频繁卡顿，处理消息的速度自然就慢了。为了验证这个想法，先用jstat看看内存使用情况： jstat -gcutil 1 1000 #1是进程号 结果如我所料，几乎1秒钟就要做一次FGC，能安安静静的做个正常的consumer才有鬼了。 赶紧留了一台consumer拿来做分析，把别的几台consumer都重启。不管怎样，先恢复消费能力再说！ 内存泄露root cause排查 1秒一次FGC，那肯定是发生内存泄露了。 二话不说，把堆dump下来先！ jmap -F -dump:format=b,file=heapDump 1 #1是进程号 生成的heapDump文件有将近2个G的大小，这么大个文件，为了不影响生产环境的机器，还是scp到本地进行分析吧！ jhat了一下，直接卡在那里不动了。没办法，祭出VisualVM来帮忙。导入文件之后，发现有一大堆HashMap的Node在那占着： 然而并不知道这是个啥，点进去看看内容，发现有一大堆node的key类型是X509CertImpl： 这时候我意识到

【推荐阅读】微服务还能火多久？>>> java程序中出现死锁问题，如果不了解排查方法，是束手无策的，今天咱们用三种方法找到死锁问题。 运行下面代码 package com.jvm.visualvm; /** * <a href="http://www.itsoku.com/archives">Java干货铺子,只生产干货，公众号：javacode2018</a> */ public class Demo4 { public static void main(String[] args) { User u1 = new User("u1"); User u2 = new User("u2"); Thread thread1 = new Thread(new SynAddRunalbe(u1, u2, 1, 2, true)); thread1.setName("thread1"); thread1.start(); Thread thread2 = new Thread(new SynAddRunalbe(u1, u2, 2, 1, false)); thread2.setName("thread2"); thread2.start(); } /** * 线程死锁等待演示 */ public static class SynAddRunalbe implements Runnable

【推荐阅读】微服务还能火多久？>>> ylbtech-资源：Java 1. 返回顶部 2. 返回顶部 · https://docs.oracle.com/javase/8/docs/ · Oracle has two products that implement Java Platform Standard Edition (Java SE) 8: Java SE Development Kit (JDK) 8 and Java SE Runtime Environment (JRE) 8. JDK 8 is a superset of JRE 8, and contains everything that is in JRE 8, plus tools such as the compilers and debuggers necessary for developing applets and applications. JRE 8 provides the libraries, the Java Virtual Machine (JVM), and other components to run applets and applications written in the Java programming language. Note that the JRE

【今日推荐】：为什么一到面试就懵逼！>>> 面试官： 出现了性能问题，该怎么去排查呢？ 程序猿： 接口响应那么慢，时间都花到哪里去了？ 运维喵： 为什么你的应用跑着跑着，CPU 就接近 100%？ 分享一些真实生产问题排查故事，看看能否涨姿势，能否 get 到其中之「趣」？ 另外，为了方便收藏，文末把 Java 程序优化及问题排查套路，整理成了葵花宝典，一定要记得收藏呦。 1. 业务催的急，心发慌的现场！ 2012 年，在一家支付公司做用户域的基础服务，每天做的事儿便是为满足业务需求，制定各种各样的 API。 某天，业务反馈线上调用查询省份地市接口频繁超时 ... ... 生产要敬畏，生产无小事。 于是乎，煎饼果子丢一旁。一边让业务同事提供调用接口时的唯一 ID（rpid，查询日志全靠它），一边找运维同事 确认网络有没有问题、服务有没有问题，在排除环境没问题的前提下，快速根据 rpid 获取日志并进行分析 。 日志记得好，排查问题没烦恼。 发现程序执行到访问数据库拿数据时总会需要花费很长时间，导致业务接口超时。 当时，分析原因有二。 原因一： 大部分接口都是读在线库，而该接口读的则是离线库，但是离线库配置的最大连接数是 2， 在 高并发情况下，拿不到数据库连接 ； 原因二： 省份地市信息为不变信息，程序并没有 借助缓存提升性能 。 寻得病症，便可对症下药。 2. 服务一启动

3 月，跳不动了？>>> 在使用jvisualVM的时候，加载400M的类示例，提示内存不足，然后中断，原来jvisualVM也需要设置java堆内存，于是修改Java_home/lib/visualvm/etc/visualvm.conf文件中visualvm_default_options="-J-client -J-Xms24 -J-Xmx256m",把256调大，然后重启jvisualVM即可 这种方式，试过不行，可能和我用的是jdk自带的jvisualVM所以上面的配置并没有效果，打不开的还是打不开。 正确的姿势是这样的 jvisualVM .exe -J-Xms512 -J-Xmx1024m jvisualvm 工具使用 jdk使用自带工具查看.hprof文件 来源： oschina 链接： https://my.oschina.net/miaojiangmin/blog/3210674

名称 作用 lombok 通过注解的形式去生成GET/SET方法，同时还可以通过注解去完成构造函数 p3c 阿里巴巴出品的java代码规范插件 GsonFormat 一键根据json文本生成java类 Maven Helper 一键查看maven依赖，查看冲突的依赖，一键进行exclude依赖 VisualVM Launcher 运行java程序的时候启动visualvm，方便查看jvm的情况 比如堆内存大小的分配 GenerateAllSetter 一键调用一个对象的所有set方法并且赋予默认值 在对象字段多的时候非常方便 Translate 最好用的翻译插件，功能很强大，界面很漂亮 Free MyBatis plugin 快速从代码跳转到mapper及从mapper返回代码;mybatis自动补全及语法错误提示 来源： oschina 链接： https://my.oschina.net/u/3568600/blog/3186603

java性能调优 jmx jmx（Java Management Extensions，即Java管理扩展） 开启远程支持 注意服务器的端口防火墙 需要在服务器上添加JVM参数来开启 -Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.port=9090 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Djava.rmi.server.hostname=localhost jstatd 安全策略文件 jstatd.policy grant codebase"file:${java.home}/../lib/tools.jar"{ permission java.security.AllPermission; }; 开启远程支持 jstatd -J-Djava.security.policy=jstatd.policy -J-Djava.rmi.server.hostname=localhost -p1099 >> /tmp/jstatd.log 2>&1 & jvisualvm 需要 jmx 和 jstatd 同时开启支持 jvisualvm