一、JVM 核心框架与常用配置JVM 内存模型主要分为堆、方法区元空间、虚拟机栈、本地方法栈和程序计数器。其中堆和方法区是垃圾回收的主要区域也是性能调优的关键。1.1 堆内存配置建议根据应用实际情况设置-Xms初始堆大小和-Xmx最大堆大小避免 JVM 在运行时动态调整堆大小带来的性能开销。通常推荐将-Xms和-Xmx设置为相同值可以防止堆扩容或缩容时的 Full GC 和内存碎片。# 示例设置堆内存为 4G且初始与最大相同 -Xms4g -Xmx4g1.2 线程栈大小配置每个线程都会分配独立的栈空间通过-Xss参数设置。在大量线程的场景下如果栈大小设置过大可能导致内存耗尽设置过小则可能引发 StackOverflowError。建议根据实际调用深度调整通常 256KB 或 512KB 足够。-Xss256k1.3 垃圾回收器选择常见垃圾回收器包括 Serial、Parallel、CMS、G1、ZGC 等。对于大部分服务端应用G1 是兼顾吞吐量与延迟的较好选择可配置-XX:UseG1GC。对于低延迟要求极高的场景可考虑 ZGC需配合大内存和较新 JDK 版本。-XX:UseG1GC二、JDK 常用命令行工具及使用JDK 自带了一系列强大的命令行工具可以帮助我们快速定位性能问题和内存泄漏。jps列出当前系统中所有 Java 进程的 PID。jstat监视虚拟机运行时状态如类加载、内存、垃圾收集等。常用jstat -gcutil pid 1000查看 GC 百分比。jmap生成堆转储快照dump 文件或查看堆内存使用详情。如jmap -dump:live,formatb,fileheap.bin pid可导出存活对象堆转储。jstack生成线程快照用于分析线程死锁、长时间等待等问题。常用jstack -l pid查看线程堆栈。jinfo查看或动态修改 JVM 参数。jcmd功能更全面的诊断命令可替代 jmap/jstack 等。命令行工具示例# 查看 GC 统计 jstat -gcutil 12345 1000 10 导出堆转储 jmap -dump:live,formatb,fileheap.hprof 12345 查看线程堆栈 jstack 12345 thread.txt三、Java 高性能编程实践以下原则参考自《Effective Java》等权威著作结合实战经验整理。3.1 集合初始化时指定大小在集合元素个数明确的场景下建议在构造时指定初始容量避免集合反复扩容带来的数据拷贝开销从而减少 CPU 和临时内存消耗。// 不推荐不断扩容产生多次数据拷贝 ListString list new ArrayList(); for (int i 0; i 1000; i) { list.add(item); } // 推荐已知元素数量直接指定初始容量 ListString list new ArrayList(1000); for (int i 0; i 1000; i) { list.add(item); }3.2 多线程场景使用并发集合在多线程环境下应当使用ConcurrentHashMap、CopyOnWriteArrayList等并发集合而不是手动同步普通集合提高并发性能。// 不推荐手动同步性能低下 MapString, String map Collections.synchronizedMap(new HashMap()); // 推荐使用 ConcurrentHashMap ConcurrentHashMapString, String map new ConcurrentHashMap(); map.put(key, value);3.3 List 转 Array 时设置 Array 的 size 为 0调用list.toArray(new T[0])比list.toArray(new T[list.size()])更高效因为 JVM 优化后零长度数组的创建成本极低且可以避免不必要的数组填充。// 推荐方式 String[] array list.toArray(new String[0]);3.4 Lambda 表达式优于匿名类方法引用优于 Lambda 表达式Lambda 表达式简化了匿名类的写法减少字节码生成提升可读性。当 Lambda 仅调用一个已有方法时使用方法引用如String::length比 Lambda 表达式更简洁且可能带来微小的性能提升。// 匿名类 list.sort(new ComparatorString() { Override public int compare(String o1, String o2) { return o1.length() - o2.length(); } }); // Lambda 表达式 list.sort((o1, o2) - o1.length() - o2.length()); // 方法引用更优 list.sort(Comparator.comparingInt(String::length));3.5 使用线程池管控线程资源避免不加控制地创建新线程而应使用线程池来统一管理防止资源耗尽。推荐使用ThreadPoolExecutor并设置合理的核心线程数、最大线程数和队列容量。ThreadPoolExecutor executor new ThreadPoolExecutor( 10, // 核心线程数 20, // 最大线程数 60L, TimeUnit.SECONDS, // 空闲线程存活时间 new LinkedBlockingQueue(100), // 有界队列 new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略 );3.6 使用 CompletableFuture 处理异步事件CompletableFuture提供了强大的异步编程能力可组合多个异步任务避免回调地狱并充分利用系统资源。CompletableFutureString future1 CompletableFuture.supplyAsync(() - fetchData()); CompletableFutureString future2 CompletableFuture.supplyAsync(() - processData()); CompletableFutureString combined future1.thenCombine(future2, (r1, r2) - r1 r2); System.out.println(combined.get());四、常用性能定位工具说明与使用4.1 JProfilerJProfiler 是一款商业 Java 性能分析工具提供 CPU、内存、线程、数据库等全方位分析。通过挂载到目标 JVM可以直观地看到热点方法、内存分配路径、线程阻塞情况等适合在开发或测试环境深度剖析。4.2 ArthasArthas 是阿里巴巴开源的 Java 在线诊断工具无需重启应用、无需修改代码即可附加到运行中的 JVM常用于排查 CPU 飙高、线程死锁、接口响应慢、内存泄漏、线上代码版本不一致等问题非常适合生产环境。4.2.1 安装与启动下载arthas-boot.jar后执行启动命令Arthas 会列出当前机器上的 Java 进程选择目标进程编号即可完成附加。# 下载启动脚本 curl -O https://arthas.aliyun.com/arthas-boot.jar 启动并选择 Java 进程 java -jar arthas-boot.jar附加成功后会进入 Arthas 交互式命令行后续所有命令都在该终端中执行。4.2.2 常用命令详解dashboard实时监控面板展示 CPU、内存、GC、线程和运行时信息适合快速观察整体健康状态。thread查看线程状态。常用thread -n 3查看 CPU 使用率最高的 3 个线程thread -b查找阻塞其他线程的源头常用于死锁排查。jvm查看 JVM 基础信息、内存、垃圾回收器和线程统计。sc查看 JVM 已加载的类信息例如sc *OrderService。sm查看类的已加载方法签名例如sm com.example.service.OrderService。jad反编译指定类的字节码确认线上运行的代码版本。watch观察方法入参、返回值、异常和执行耗时适合定位偶发数据问题。trace追踪方法调用链路和各节点耗时适合分析接口响应慢的瓶颈。stack输出方法的实时调用栈查看某方法被谁调用。monitor统计方法调用次数、成功率和平均耗时适合做周期性监控。heapdump生成堆转储文件用于 MAT、JProfiler 等工具做内存分析。logger动态查看或调整日志级别无需改配置重启。redefine热更新已加载类适合紧急修复但在生产环境必须谨慎评估。ognl执行 OGNL 表达式查看静态字段、变量或对象状态。4.2.3 常用命令示例# 查看整体运行状态 dashboard 查看 CPU 使用率最高的 3 个线程 thread -n 3 查找线程死锁或阻塞源头 thread -b 追踪接口调用链路及耗时 trace com.example.controller.OrderController getOrder 观察方法入参、返回值和异常 watch com.example.service.OrderService getOrder {params, returnObj, throwExp} -x 3 反编译类确认线上代码版本 jad com.example.controller.OrderController 导出堆转储用于内存分析 heapdump /tmp/heap.hprof 动态调整日志级别 logger --name ROOT --level info4.2.4 实战排查示例以一个订单接口响应变慢为例可以按下述顺序排查执行dashboard先确认 CPU、内存和 GC 是否异常。如果 CPU 持续偏高执行thread -n 3找到消耗 CPU 最高的线程再结合线程栈定位热点方法。如果怀疑接口内部调用慢执行trace com.example.controller.OrderController getOrder根据调用链路中各方法的耗时逐层下钻。如果怀疑数据或参数异常执行watch com.example.service.OrderService getOrder {params, returnObj, throwExp} -x 3观察真实入参、返回值和异常信息。如果怀疑代码版本不对执行jad com.example.controller.OrderController反编译确认。分析完成后执行quit退出当前连接如需完全卸载请执行stop。4.2.5 使用注意事项watch、trace、stack等命令会做字节码增强存在一定性能开销生产环境应避免长时间开启也尽量缩小追踪范围。redefine热更新只在重启前临时生效且只兼容部分改动生产环境应谨慎使用并做好回退预案。拿到内存 dump 文件后尽量在本地或专用分析环境用 MAT、JProfiler 继续分析避免占用生产机器资源。Arthas 附加的是目标应用进程自身排查完成后应执行quit或stop及时退出减少不必要的字节码增强残留。4.3 BTraceBTrace 是 Sun 公司推出的动态追踪工具可以通过编写 BTrace 脚本在不重启应用的情况下安全地注入追踪代码获取方法参数、返回值、调用耗时等信息。它与 Arthas 的 watch/trace 功能类似但需要编写脚本灵活性更高。五、JVM 性能排查思路与典型案例当线上应用出现性能问题时可以按照以下思路排查监控告警确认 CPU、内存、GC、线程数等指标是否异常。定位问题类型是内存泄漏OOM、GC 频繁、线程阻塞还是 CPU 高负载收集现场信息使用 jstack、jmap、jstat 或 Arthas 导出堆转储、线程快照、GC 日志等。分析数据借助 MATMemory Analyzer Tool、JProfiler 或 Arthas 分析堆转储找出内存泄漏对象通过线程栈分析死锁或阻塞原因。验证与修复根据分析结果修改代码或 JVM 参数灰度验证并上线。5.1 JVM 堆内存 OOM现象程序运行一段时间后响应越来越慢页面难以打开处理速度下降网络连接超时CPU 飙升。最终可能抛出java.lang.OutOfMemoryError: Java heap space。解决办法使用jmap -histo:live pid查看存活对象数量排序快速定位内存占用最多的类。通过jmap -dump:live,formatb,fileheap.hprof pid导出堆转储用 MAT 或 JProfiler 分析 Dominator Tree找出内存泄漏路径。使用 Arthas 的heapdump命令导出 dump 文件并用vmtool或ognl查看对象引用。可直接通过命令行管道输出 Top N 对象数量jmap -histo:live pid | head -n 205.2 JVM 元空间MetaspaceOOM现象应用抛出java.lang.OutOfMemoryError: Metaspace通常是因为加载了过多的类如动态代理、反射、大量第三方库导致元空间不足。解决办法检查-XX:MaxMetaspaceSize是否设置过小可适当调大如-XX:MaxMetaspaceSize256m。使用jstat -gc观察 MU、MC 等指标确认元空间使用趋势。排查是否存在类加载器泄漏可通过jmap -clstats查看类加载器信息。检查代码中是否大量使用动态代理如 CGLIB、Javassist但未及时回收。5.3 JVM 堆外内存泄漏直接内存 OOM现象操作系统层面内存占用持续增大但 dump 出来的 JVM 堆内存正常使用top命令观察进程内存RES不断增长最终可能被操作系统 OOM Killer 杀死。解决办法手动触发 Full GC 观察内存释放情况执行jmap -histo:live pid或jcmd pid GC.run会触发 FGC但直接内存DirectByteBuffer的回收依赖于 GC 后清理器的调用因此可能不会立即释放。使用pmap -x pid查看内存映射定位占用大的内存块通常直接内存以 64MB 大小的块分配。检查是否大量使用 NIO如 Netty并正确释放 ByteBuf检查-XX:MaxDirectMemorySize是否设置。可借助jcmd pid VM.native_memory summary查看本机内存使用详情需开启 NMT。5.4 JVM 内存正常但 GC 极慢现象整体内存使用正常GC 频率也正常但 GC 日志显示 Young GC 和 Full GC 耗时长达几十秒甚至分钟级STW 严重程序表现极差。解决办法检查磁盘 IO 是否异常因为 GC 日志写入或 swap 换页可能导致严重阻塞。检查系统是否开启了 swap导致 JVM 内存被换出到磁盘GC 时访问内存极慢。可通过free -m查看 swap 使用量必要时关闭 swap 或调整 swappiness。检查是否有大量页错误page fault可通过vmstat观察。分析 GC 日志中sys或real时间明显大于user时间说明存在系统级别的等待通常是磁盘 IO 或内存瓶颈。