1. JConsole入门认识你的JVM监控利器第一次接触JConsole是在三年前的一个深夜当时线上服务突然出现内存泄漏整个团队束手无策。直到一位资深工程师打开这个神秘工具不到十分钟就锁定了问题根源——一个被遗忘的静态Map在不断膨胀。从那时起我就深深体会到了JConsole的价值。JConsole是JDK自带的图形化监控工具基于JMXJava Management Extensions技术实现。它就像给JVM装上了X光机能实时透视堆内存、线程、类加载等关键指标。与专业APM工具相比JConsole最大的优势是开箱即用——只要装了JDK在命令行输入jconsole就能启动。启动后会看到两类连接选项本地连接自动检测本机所有Java进程选择即连远程连接需要配置JMX端口和安全策略适合生产环境这里有个实用技巧当需要监控Tomcat等容器时建议在catalina.sh中添加以下参数JAVA_OPTS$JAVA_OPTS -Dcom.sun.management.jmxremote.port9090 -Dcom.sun.management.jmxremote.sslfalse -Dcom.sun.management.jmxremote.authenticatefalse2. 内存监控实战揪出内存泄漏的元凶内存问题是最常见的性能瓶颈。去年我们有个服务频繁Full GC通过JConsole的内存标签页发现老年代Old Gen占用曲线呈锯齿状上升每次GC后最低点越来越高——这是典型的内存泄漏特征。关键观察点堆内存趋势图健康状态应该呈锯齿状GC后回落内存池详情Eden区新对象诞生地频繁Minor GCSurvivor区存放GC后存活的对象Old Gen长期存活对象Full GC主要区域非堆内存包含Metaspace类元数据、Code CacheJIT编译代码等遇到内存异常时可以手动触发GC点击执行GC按钮观察内存回收效果对比已使用和提交内存的差值判断是否存在内存碎片重点监控Old Gen如果持续增长且GC无法回收可能存在内存泄漏我曾用这个方法发现过一个Spring缓存配置错误Cacheable注解没有设置过期时间导致缓存数据无限增长。通过JConsole的内存池对比很快定位到问题所在。3. 线程分析破解死锁难题线程死锁就像交通堵塞四个线程互相等待对方释放锁导致系统卡死。上个月我们的支付系统就遭遇这种情况交易量突增时系统完全挂死。诊断步骤查看线程标签页的活动线程曲线是否达到峰值点击检测死锁按钮自动分析支持synchronized和Lock两种锁检查线程堆栈重点关注BLOCKED状态的线程有个真实案例线程A持有order表的锁等待payment表线程B正好相反。JConsole不仅检测出死锁还直接显示了这两个线程的堆栈信息。我们在代码中用tryLock()替换synchronized并设置超时时间问题迎刃而解。线程监控技巧给重要线程设置有意义的名字如PaymentProcessor-1监控守护线程数量避免意外终止关注线程状态转换频率频繁BLOCKED可能预示锁竞争激烈4. 高级技巧MBean的隐藏力量大多数开发者只使用JConsole的基础监控功能其实它的MBean标签页才是真正的宝藏。通过MBean我们可以1. 动态调整参数 比如修改HotSpotDiagnostic的VMOptions实时调整JVM参数。曾有个服务因为元空间溢出我们通过MBean临时增加了MaxMetaspaceSize避免了服务重启。2. 执行诊断操作触发堆转储com.sun.management:typeHotSpotDiagnostic的dumpHeap操作获取线程转储java.lang:typeThreading的dumpAllThreads查看类加载详情java.lang:typeClassLoading3. 自定义监控 通过注解ManagedResource暴露自己的MBean比如监控订单处理队列深度ManagedResource public class OrderQueueMonitor { ManagedAttribute public int getPendingOrders() { return orderQueue.size(); } }5. 生产环境实战远程监控安全配置直接在生产服务器上开JConsole显然不安全我们需要安全的远程连接方案。下面是我在金融项目中使用的配置安全连接四要素启用SSL加密-Dcom.sun.management.jmxremote.ssltrue -Dcom.sun.management.jmxremote.ssl.need.client.authtrue配置密码认证-Dcom.sun.management.jmxremote.authenticatetrue -Dcom.sun.management.jmxremote.password.file../conf/jmxremote.password限制访问IP-Dcom.sun.management.jmxremote.access.file../conf/jmxremote.access防火墙规则 只开放特定JMX端口如9091禁止公网访问常见踩坑点密码文件权限必须为600否则JVM拒绝启动RMI端口随机分配需固定-Dcom.sun.management.jmxremote.rmi.port云服务器需同时配置安全组和主机防火墙有一次凌晨三点被叫醒处理线上问题因为同事忘记设置java.rmi.server.hostname导致监控服务器连不上。这个教训让我养成了写部署检查清单的习惯。6. 性能调优实战从监控到优化监控的终极目标是优化。通过长期观察JConsole数据我总结出这些经验内存优化如果Eden区GC频繁适当增加-Xmn年轻代大小Survivor区对象晋升过快调整-XX:SurvivorRatioOld Gen持续增长检查大对象分配如-XX:PrintTenuringDistribution线程优化线程数CPU核心数*(1等待时间/计算时间)使用-XX:PrintGCDetails分析GC对线程的影响避免在频繁执行的代码路径上创建线程有个电商项目通过JConsole发现高峰时段CMS GC耗时超过2秒。我们最终通过以下调整将STW时间控制在200ms内-XX:UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction70 -XX:CMSParallelRemarkEnabled记住调优没有银弹。我习惯用JConsole建立性能基线任何修改后都对比关键指标的变化。就像老中医把脉需要长期观察才能准确诊断。
1. JConsole入门认识你的JVM监控利器第一次接触JConsole是在三年前的一个深夜当时线上服务突然出现内存泄漏整个团队束手无策。直到一位资深工程师打开这个神秘工具不到十分钟就锁定了问题根源——一个被遗忘的静态Map在不断膨胀。从那时起我就深深体会到了JConsole的价值。JConsole是JDK自带的图形化监控工具基于JMXJava Management Extensions技术实现。它就像给JVM装上了X光机能实时透视堆内存、线程、类加载等关键指标。与专业APM工具相比JConsole最大的优势是开箱即用——只要装了JDK在命令行输入jconsole就能启动。启动后会看到两类连接选项本地连接自动检测本机所有Java进程选择即连远程连接需要配置JMX端口和安全策略适合生产环境这里有个实用技巧当需要监控Tomcat等容器时建议在catalina.sh中添加以下参数JAVA_OPTS$JAVA_OPTS -Dcom.sun.management.jmxremote.port9090 -Dcom.sun.management.jmxremote.sslfalse -Dcom.sun.management.jmxremote.authenticatefalse2. 内存监控实战揪出内存泄漏的元凶内存问题是最常见的性能瓶颈。去年我们有个服务频繁Full GC通过JConsole的内存标签页发现老年代Old Gen占用曲线呈锯齿状上升每次GC后最低点越来越高——这是典型的内存泄漏特征。关键观察点堆内存趋势图健康状态应该呈锯齿状GC后回落内存池详情Eden区新对象诞生地频繁Minor GCSurvivor区存放GC后存活的对象Old Gen长期存活对象Full GC主要区域非堆内存包含Metaspace类元数据、Code CacheJIT编译代码等遇到内存异常时可以手动触发GC点击执行GC按钮观察内存回收效果对比已使用和提交内存的差值判断是否存在内存碎片重点监控Old Gen如果持续增长且GC无法回收可能存在内存泄漏我曾用这个方法发现过一个Spring缓存配置错误Cacheable注解没有设置过期时间导致缓存数据无限增长。通过JConsole的内存池对比很快定位到问题所在。3. 线程分析破解死锁难题线程死锁就像交通堵塞四个线程互相等待对方释放锁导致系统卡死。上个月我们的支付系统就遭遇这种情况交易量突增时系统完全挂死。诊断步骤查看线程标签页的活动线程曲线是否达到峰值点击检测死锁按钮自动分析支持synchronized和Lock两种锁检查线程堆栈重点关注BLOCKED状态的线程有个真实案例线程A持有order表的锁等待payment表线程B正好相反。JConsole不仅检测出死锁还直接显示了这两个线程的堆栈信息。我们在代码中用tryLock()替换synchronized并设置超时时间问题迎刃而解。线程监控技巧给重要线程设置有意义的名字如PaymentProcessor-1监控守护线程数量避免意外终止关注线程状态转换频率频繁BLOCKED可能预示锁竞争激烈4. 高级技巧MBean的隐藏力量大多数开发者只使用JConsole的基础监控功能其实它的MBean标签页才是真正的宝藏。通过MBean我们可以1. 动态调整参数 比如修改HotSpotDiagnostic的VMOptions实时调整JVM参数。曾有个服务因为元空间溢出我们通过MBean临时增加了MaxMetaspaceSize避免了服务重启。2. 执行诊断操作触发堆转储com.sun.management:typeHotSpotDiagnostic的dumpHeap操作获取线程转储java.lang:typeThreading的dumpAllThreads查看类加载详情java.lang:typeClassLoading3. 自定义监控 通过注解ManagedResource暴露自己的MBean比如监控订单处理队列深度ManagedResource public class OrderQueueMonitor { ManagedAttribute public int getPendingOrders() { return orderQueue.size(); } }5. 生产环境实战远程监控安全配置直接在生产服务器上开JConsole显然不安全我们需要安全的远程连接方案。下面是我在金融项目中使用的配置安全连接四要素启用SSL加密-Dcom.sun.management.jmxremote.ssltrue -Dcom.sun.management.jmxremote.ssl.need.client.authtrue配置密码认证-Dcom.sun.management.jmxremote.authenticatetrue -Dcom.sun.management.jmxremote.password.file../conf/jmxremote.password限制访问IP-Dcom.sun.management.jmxremote.access.file../conf/jmxremote.access防火墙规则 只开放特定JMX端口如9091禁止公网访问常见踩坑点密码文件权限必须为600否则JVM拒绝启动RMI端口随机分配需固定-Dcom.sun.management.jmxremote.rmi.port云服务器需同时配置安全组和主机防火墙有一次凌晨三点被叫醒处理线上问题因为同事忘记设置java.rmi.server.hostname导致监控服务器连不上。这个教训让我养成了写部署检查清单的习惯。6. 性能调优实战从监控到优化监控的终极目标是优化。通过长期观察JConsole数据我总结出这些经验内存优化如果Eden区GC频繁适当增加-Xmn年轻代大小Survivor区对象晋升过快调整-XX:SurvivorRatioOld Gen持续增长检查大对象分配如-XX:PrintTenuringDistribution线程优化线程数CPU核心数*(1等待时间/计算时间)使用-XX:PrintGCDetails分析GC对线程的影响避免在频繁执行的代码路径上创建线程有个电商项目通过JConsole发现高峰时段CMS GC耗时超过2秒。我们最终通过以下调整将STW时间控制在200ms内-XX:UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction70 -XX:CMSParallelRemarkEnabled记住调优没有银弹。我习惯用JConsole建立性能基线任何修改后都对比关键指标的变化。就像老中医把脉需要长期观察才能准确诊断。
 MySQL事务(上)，事务的四大特性，事务的操作方式，事务的隔离级别)
