Java虚拟机三件套解析

本文涉及的产品
全局流量管理 GTM,标准版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
日志服务 SLS,月写入数据量 50GB 1个月
简介: Java虚拟机(JVM)生成3个关键工件,这些工件对于优化性能和解决生产问题很有用。这些工件是:垃圾收集(GC)日志线程转储(ThreadDump)堆转储(HeapDump 在本文中,我将尝试简要解析下这3个关键工件,描述下在什么场景中使用它们,它们的外观如何,如何捕获它们,如何分析它们及其之间的差异。

      Java虚拟机(JVM)生成3个关键工件,这些工件对于优化性能和解决生产问题很有用。这些工件是:

  • 垃圾收集(GC)日志
  • 线程转储(ThreadDump)
  • 堆转储(HeapDump

      在本文中,我将尝试简要解析下这3个关键工件,描述下在什么场景中使用它们,它们的外观如何,如何捕获它们,如何分析它们及其之间的差异。      

垃圾收集日志GC Log)

       1、什么是GC日志?

      GC日志包含垃圾回收事件的相关信息。它将指示运行了多少个GC事件,它们是什么类型的GC事件(即,年轻的GC还是全局的GC),每个GC事件暂停了应用程序多长时间,每个GC事件回收了多少个对象。

       2、GC日志的外观如何?

       这里以G1垃圾回收策略为例,展示部分样本的垃圾收集日志文件,内容如下所示:


[administrator@JavaLangOutOfMemory luga %]less echo-admin-gc.log
... ...
2015-09-14T12:32:24.398-0700: 0.356: [GC pause (G1 Evacuation Pause) (young), 0.0215287 secs]
   [Parallel Time: 20.0 ms, GC Workers: 8]
      [GC Worker Start (ms): Min: 355.9, Avg: 356.3, Max: 358.4, Diff: 2.4]
      [Ext Root Scanning (ms): Min: 0.0, Avg: 6.4, Max: 16.7, Diff: 16.7, Sum: 51.4]
      [Update RS (ms): Min: 0.0, Avg: 1.0, Max: 2.5, Diff: 2.5, Sum: 8.2]
         [Processed Buffers: Min: 0, Avg: 1.1, Max: 5, Diff: 5, Sum: 9]
      [Scan RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
      [Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.1, Diff: 0.1, Sum: 0.1]
      [Object Copy (ms): Min: 2.9, Avg: 11.9, Max: 17.5, Diff: 14.6, Sum: 95.3]
      [Termination (ms): Min: 0.0, Avg: 0.1, Max: 0.2, Diff: 0.2, Sum: 0.9]
         [Termination Attempts: Min: 1, Avg: 2.5, Max: 5, Diff: 4, Sum: 20]
      [GC Worker Other (ms): Min: 0.0, Avg: 0.1, Max: 0.1, Diff: 0.1, Sum: 0.5]
      [GC Worker Total (ms): Min: 17.5, Avg: 19.6, Max: 19.9, Diff: 2.4, Sum: 156.5]
      [GC Worker End (ms): Min: 375.8, Avg: 375.9, Max: 375.9, Diff: 0.1]
   [Code Root Fixup: 0.0 ms]
   [Code Root Purge: 0.0 ms]
   [Clear CT: 0.5 ms]
   [Other: 1.0 ms]
      [Choose CSet: 0.0 ms]
      [Ref Proc: 0.4 ms]
      [Ref Enq: 0.0 ms]
      [Redirty Cards: 0.4 ms]
      [Humongous Register: 0.0 ms]
      [Humongous Reclaim: 0.0 ms]
      [Free CSet: 0.0 ms]
   [Eden: 12.0M(12.0M)->0.0B(14.0M) Survivors: 0.0B->2048.0K Heap: 12.6M(252.0M)->7848.3K(252.0M)]
 [Times: user=0.08 sys=0.00, real=0.02 secs] 
2015-09-14T12:32:24.932-0700: 0.889: [GC pause (G1 Evacuation Pause) (young), 0.0469650 secs]

       3、什么场景下使用GC日志?

      垃圾收集日志用于研究应用程序的GC和内存性能。用于优化GC暂停时间,用于确定应用程序的最佳内存大小,还用于解决与内存相关的问题。

       4、如何生成GC日志?

       在应用程序启动文件中,可以通过传递以下JVM参数来生成垃圾收集日志,具体如下:

       对于Java 8以及之前的版本,具体配置参数:


-XX:+PrintGC
-XX:+PrintGCDateStamps
-Xloggc:<file-path>

      对于从Java 9之后的Java版本:


-Xlog:gc *:file = <file-path>
file-path:是要写入垃圾收集日志文件的位置

       5、如何理解GC日志?

      垃圾收集日志格式会有所不同,具体取决于我们当前环境中的JVM供应商(Oracle、HP、IBM、Azul等及其他),Java版本(1.5、5、6、7、8、9、10、11、12、15…),垃圾收集算法(串行,并行,CMS,G1,Shenandoah,Z GC)和JVM参数。因此,没有一种可用的标准化格式。

       6、哪些工具可以分析GC日志?

      有多种垃圾收集日志分析工具。根据笔者经验,目前比较受欢迎的一些工具:GCeasy、IBM GC和内存可视化工具、HP JMeter、Google Garbage Cat及其他。      

线程转储(ThreadDump

       1、什么是线程转储?

      线程转储是指在某一时间点在应用程序中运行的所有线程的快照。它包含有关应用程序中每个线程的所有信息,例如:线程状态,线程ID,本机ID,线程名称,堆栈跟踪,优先级等等。

       2、线程转储的外观如何?

      常见线程转储文件内容如下所示:


2016-12-03 10:37:28
Full thread dump Java HotSpot(TM) 64-Bit Server VM (23.7-b01 mixed mode):
"Attach Listener" daemon prio=10 tid=0x000000001b03e000 nid=0x3954 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE
"InvoiceGeneratedQC-A99-6" prio=10 tid=0x00002b7cfc6fb000 nid=0x4479 runnable [0x00002b7d17ab8000]
   java.lang.Thread.State: RUNNABLE
  at com.buggyCompany.rt.util.ItinerarySegmentProcessor.setConnectingFlight(ItinerarySegmentProcessor.java:380)
  at com.buggyCompany.rt.util.ItinerarySegmentProcessor.processTripType0(ItinerarySegmentProcessor.java:366)
  at com.buggyCompany.rt.util.ItinerarySegmentProcessor.processItineraryByTripType(ItinerarySegmentProcessor.java:254)
  at com.buggyCompany.rt.util.ItinerarySegmentProcessor.templateMethod(ItinerarySegmentProcessor.java:399)
  at com.buggyCompany.qc.gds.InvoiceGeneratedFacade.readTicketImage(InvoiceGeneratedFacade.java:252)
  at com.buggyCompany.qc.gds.InvoiceGeneratedFacade.doOrchestrate(InvoiceGeneratedFacade.java:151)
  at com.buggyCompany.framework.gdstask.BaseGDSFacade.orchestrate(BaseGDSFacade.java:32)
  at com.buggyCompany.framework.gdstask.BaseGDSFacade.doWork(BaseGDSFacade.java:22)
  at com.buggyCompany.framework.concurrent.buggyCompanyCallable.call(buggyCompanyCallable.java:80)
  at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
  at java.util.concurrent.FutureTask.run(FutureTask.java:166)
  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
  at java.lang.Thread.run(Thread.java:722)
"InvoiceGeneratedQC-H87-6" prio=10 tid=0x00002b7cfc94a000 nid=0x4472 runnable [0x00002b7d16fad000]
   java.lang.Thread.State: RUNNABLE
  at com.buggyCompany.rt.util.ItinerarySegmentProcessor.setConnectingFlight(ItinerarySegmentProcessor.java:380)
  at com.buggyCompany.rt.util.ItinerarySegmentProcessor.processTripType0(ItinerarySegmentProcessor.java:366)
  at com.buggyCompany.rt.util.ItinerarySegmentProcessor.processItineraryByTripType(ItinerarySegmentProcessor.java:254)
  at com.buggyCompany.rt.util.ItinerarySegmentProcessor.templateMethod(ItinerarySegmentProcessor.java:399)
  at com.buggyCompany.qc.gds.InvoiceGeneratedFacade.readTicketImage(InvoiceGeneratedFacade.java:252)
  at com.buggyCompany.qc.gds.InvoiceGeneratedFacade.doOrchestrate(InvoiceGeneratedFacade.java:151)
  at com.buggyCompany.framework.gdstask.BaseGDSFacade.orchestrate(BaseGDSFacade.java:32)
  at com.buggyCompany.framework.gdstask.BaseGDSFacade.doWork(BaseGDSFacade.java:22)
  at com.buggyCompany.framework.concurrent.buggyCompanyCallable.call(buggyCompanyCallable.java:80)
  at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
  at java.util.concurrent.FutureTask.run(FutureTask.java:166)
  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
  at java.lang.Thread.run(Thread.java:722)

       3、在什么场景下使用线程转储?

      线程转储主要用于解决生产问题,例如CPU尖峰,应用程序无响应,响应时间短,线程挂起,内存消耗高。

       4、如何生成线程转储?

      可以使用8个不同的选项从正在运行的应用程序中捕获线程转储。可参考之前的文章:Java ThreadDump 生成解析。进行线程转储的最常见选择是使用“ Jstack”工具。Jstack工具位于{JDK_HOME}/bin文件夹中。这是捕获线程转储所需发出的命令:


[administrator@JavaLangOutOfMemory luga %]jstack -l  <pid> > <file-path>
pid:是应用程序的进程ID,应捕获其线程转储
file-path:是将写入线程转储的文件路径。

       5、如何理解线程转储?

     可参考之前的文章:Java ThreadDump 生成解析

      6、使用哪些工具来分析线程转储?

      以下是使用最广泛的线程转储分析工具:fastThread、Samurai、IBM Thread&Monitor分析器、Visual VM及其他等等。      

堆转储(HeapDump

       1、什么是堆转储?

      堆转储是指在某一时间点应用程序内存的快照。它包含各种各样的信息,例如内存中的对象是什么,它们携带的值是什么,大小是什么,它们引用的其他对象是什么等。

       2、堆转储的外观如何?

      普通的文件,通常以指定文件类型生成,例如,可生成.phrof后缀类型,或直接heapdump等。(注意:此文件采用二进制格式。因此实际上不易阅读)。

      3、堆转储在什么场景下使用?

      堆转储主要用于解决与内存相关的OutOfMemoryError问题。

     4、如何生成堆转储?

    可以使用7个不同的选项从运行的应用程序中捕获堆转储。可参考之前的文章:Java HeapDump 生成解析进行堆转储的最常见选项是使用“ Jmap”工具。Jmap工具位于{JDK_HOME}/bin文件夹中。具体命令如下:


[administrator@JavaLangOutOfMemory luga %]jmap -dump:format = b,file = <文件路径> <pid>
pid:Java进程ID,应捕获其堆转储
file-path:堆转储将写入的文件路径。

       5、如何理解堆转储?

      堆转储文件为二进制格式,并且通常较大。除此之外,它们的格式严重缺乏文档。因此,必须使用堆转储分析工具来分析和理解它们。

       6、使用哪些工具来分析堆转储?

      以下是使用最广泛的堆转储分析工具:Eclipse MAT、HeapHero、JVisualVM及其他。

相关文章
|
8天前
|
监控 Java 应用服务中间件
高级java面试---spring.factories文件的解析源码API机制
【11月更文挑战第20天】Spring Boot是一个用于快速构建基于Spring框架的应用程序的开源框架。它通过自动配置、起步依赖和内嵌服务器等特性,极大地简化了Spring应用的开发和部署过程。本文将深入探讨Spring Boot的背景历史、业务场景、功能点以及底层原理,并通过Java代码手写模拟Spring Boot的启动过程,特别是spring.factories文件的解析源码API机制。
29 2
|
12天前
|
Java
轻松上手Java字节码编辑:IDEA插件VisualClassBytes全方位解析
本插件VisualClassBytes可修改class字节码,包括class信息、字段信息、内部类,常量池和方法等。
64 6
|
19天前
|
存储 Java 编译器
Java内存模型(JMM)深度解析####
本文深入探讨了Java内存模型(JMM)的工作原理,旨在帮助开发者理解多线程环境下并发编程的挑战与解决方案。通过剖析JVM如何管理线程间的数据可见性、原子性和有序性问题,本文将揭示synchronized关键字背后的机制,并介绍volatile关键字和final关键字在保证变量同步与不可变性方面的作用。同时,文章还将讨论现代Java并发工具类如java.util.concurrent包中的核心组件,以及它们如何简化高效并发程序的设计。无论你是初学者还是有经验的开发者,本文都将为你提供宝贵的见解,助你在Java并发编程领域更进一步。 ####
|
4天前
|
存储 安全 Java
Java多线程编程中的并发容器:深入解析与实战应用####
在本文中,我们将探讨Java多线程编程中的一个核心话题——并发容器。不同于传统单一线程环境下的数据结构,并发容器专为多线程场景设计,确保数据访问的线程安全性和高效性。我们将从基础概念出发,逐步深入到`java.util.concurrent`包下的核心并发容器实现,如`ConcurrentHashMap`、`CopyOnWriteArrayList`以及`BlockingQueue`等,通过实例代码演示其使用方法,并分析它们背后的设计原理与适用场景。无论你是Java并发编程的初学者还是希望深化理解的开发者,本文都将为你提供有价值的见解与实践指导。 --- ####
|
4天前
|
Java 测试技术 API
Java 反射机制:深入解析与应用实践
《Java反射机制:深入解析与应用实践》全面解析Java反射API,探讨其内部运作原理、应用场景及最佳实践,帮助开发者掌握利用反射增强程序灵活性与可扩展性的技巧。
|
9天前
|
存储 算法 Java
Java Set深度解析:为何它能成为“无重复”的代名词?
Java的集合框架中,Set接口以其“无重复”特性著称。本文解析了Set的实现原理,包括HashSet和TreeSet的不同数据结构和算法,以及如何通过示例代码实现最佳实践。选择合适的Set实现类和正确实现自定义对象的hashCode()和equals()方法是关键。
21 4
|
12天前
|
Java 编译器 数据库连接
Java中的异常处理机制深度解析####
本文深入探讨了Java编程语言中异常处理机制的核心原理、类型及其最佳实践,旨在帮助开发者更好地理解和应用这一关键特性。通过实例分析,揭示了try-catch-finally结构的重要性,以及如何利用自定义异常提升代码的健壮性和可读性。文章还讨论了异常处理在大型项目中的最佳实践,为提高软件质量提供指导。 ####
|
17天前
|
存储 设计模式 分布式计算
Java中的多线程编程:并发与并行的深度解析####
在当今软件开发领域,多线程编程已成为提升应用性能、响应速度及资源利用率的关键手段之一。本文将深入探讨Java平台上的多线程机制,从基础概念到高级应用,全面解析并发与并行编程的核心理念、实现方式及其在实际项目中的应用策略。不同于常规摘要的简洁概述,本文旨在通过详尽的技术剖析,为读者构建一个系统化的多线程知识框架,辅以生动实例,让抽象概念具体化,复杂问题简单化。 ####
|
16天前
|
存储 分布式计算 Java
存算分离与计算向数据移动:深度解析与Java实现
【11月更文挑战第10天】随着大数据时代的到来,数据量的激增给传统的数据处理架构带来了巨大的挑战。传统的“存算一体”架构,即计算资源与存储资源紧密耦合,在处理海量数据时逐渐显露出其局限性。为了应对这些挑战,存算分离(Disaggregated Storage and Compute Architecture)和计算向数据移动(Compute Moves to Data)两种架构应运而生,成为大数据处理领域的热门技术。
38 2
|
16天前
|
设计模式 安全 Java
Java编程中的单例模式深入解析
【10月更文挑战第31天】在编程世界中,设计模式就像是建筑中的蓝图,它们定义了解决常见问题的最佳实践。本文将通过浅显易懂的语言带你深入了解Java中广泛应用的单例模式,并展示如何实现它。

推荐镜像

更多