Java

字节码#xff08;Bytecode#xff09;解释成机器码并执行#xff0c;负责内存管理、线程管理、垃圾回收…Java

Java

字节码Bytecode解释成机器码并执行负责内存管理、线程管理、垃圾回收等功能。

JVM

类加载子系统Class

内存中的过程并为这些类分配内存、解析依赖、执行初始化并为类创建对应的

Java

加载Loading验证Verification准备Preparation解析Resolution初始化Initialization

有些文档也会将

这是类加载过程的第一步类加载器根据类的全限定名包括包名找到对应的

.class

对象用来表示这个类的元数据。

加载阶段会通过类加载器完成。

加载过程涉及

双亲委派模型

请求父加载器加载类若父加载器无法加载再由当前类加载器加载。

查找

.class

文件格式规范。

元数据验证检查类中的元数据信息是否合理。

例如类是否继承了非法的父类、类的方法签名是否正确等。

字节码验证对类的方法中的字节码进行验证确保指令序列是合法的、符合逻辑的。

符号引用验证对符号引用进行验证确保所有引用的类、方法、字段都存在并且可访问。

验证阶段保证了字节码不会对

JVM

会为类的静态变量分配内存并将其初始化为默认值并非编写代码时的赋值。

此阶段主要是分配内存而不执行具体的初始化操作。

类中的静态字段会被赋予默认值

数字类型如

true将在初始化阶段赋值。

非静态字段是在类被实例化时赋值的类加载阶段不进行赋值。

解析Resolution

解析阶段是将类的符号引用替换为直接引用的过程。

符号引用是指在字节码中通过字符串等符号来引用类、字段、方法解析过程会将这些符号引用解析为内存地址的直接引用。

解析过程会涉及以下几类引用

Class

对象。

字段解析将符号引用的字段解析为实际的内存位置。

方法解析将符号引用的方法解析为实际的可执行代码地址。

接口方法解析针对接口中的方法引用进行解析。

NoSuchFieldError

这是类加载的最后一个阶段也是执行静态变量赋值和静态代码块的阶段。

在这个阶段JVM

会根据程序员的指令对类的静态变量进行显式初始化并执行静态代码块。

类初始化的具体顺序是

父类静态初始化优先于子类静态初始化。

静态变量按照它们在类中的声明顺序进行初始化。

执行静态代码块。

类加载时机

启动时就加载所有的类而是在类被首次主动使用时才加载。

这种按需加载机制被称为

操作。

调用类的静态方法。

访问类的静态字段。

通过反射调用类。

初始化子类时先初始化父类。

JVM

main

模块中。

是引导类加载器与应用类加载器之间的一个中间层级用于支持多种库和平台相关的类。

Application

负责加载用户类路径classpath下的类包括用户自定义的类和第三方库。

使用

.jar

双亲委派模型这是类加载器设计中的核心机制。

它的工作原理是当一个类加载器收到类加载请求时它会首先将该请求委托给父加载器去处理只有当父加载器无法加载时才由当前加载器自己去加载。

这种模型有以下特点

安全性防止核心类库如

java.lang.String被自定义类加载器加载保证核心类库的唯一性和安全性。

类的唯一性同一个类在

JVM

内存中只会被加载一次除非使用不同的类加载器保证了类的唯一性。

防止重复加载通过父加载器优先机制避免不同类加载器重复加载同一个类。

运行时数据区Runtime

Area是用于存储类结构信息的内存区域。

它保存了每个类的元数据信息例如类的名称、访问修饰符、字段、方法、常量池等。

方法区是

JVM

规范中的一部分是堆外内存的一部分属于非堆区域。

它与堆相对独立主要存储与类和常量相关的数据。

**它是线程共享的区域。

**具有以下特点

存储内容

类元数据每个类的结构信息包括类名、父类名、访问修饰符、接口信息等。

字段和方法信息包括字段的名称、类型和方法的名称、签名等。

常量池Constant

Pool存储编译时生成的字面量和符号引用如字符串字面量、方法和字段的符号引用。

静态变量存储类的静态字段。

类的静态方法和代码类中的字节码和方法相关的信息也存储在这里。

JVM

关闭时方法区也会被销毁。

大小方法区可以设置大小但如果装载的类太多方法区可能会导致内存不足出现

OutOfMemoryError:

的内存是有限的如果应用程序动态生成大量类或者使用了大量字符串常量容易导致内存不足的错误比如

OutOfMemoryError:

那样受限可以动态扩展。

默认情况下元空间的大小是由系统内存决定的。

配置灵活性可以通过以下

JVM

-XX:MetaspaceSize设置元空间的初始大小。

当元空间使用达到这个值时JVM

会触发垃圾回收来清理不再使用的类。

-XX:MaxMetaspaceSize设置元空间的最大大小。

元空间可以动态扩展但如果达到这个限制就会抛出

OutOfMemoryError:

错误。

-XX:CompressedClassSpaceSize指定类指针的压缩空间大小。

通常默认大小为

1GB适用于

JVM。

-XX:UseCompressedClassPointers启用压缩类指针节省内存空间。

PermGen

中非常重要的内存区域主要用于类的加载、运行时常量池的维护和类的相关信息存储。

其作用包括

支持类加载机制JVM

加载的每一个类其相关的元数据都会存储在方法区中。

支持常量的引用与解析运行时常量池中的数据如方法引用、字段引用、字符串常量存储在方法区内。

支持静态变量存储方法区中还存储类的静态变量所有类的静态变量在内存中的唯一副本存放于方法区。

垃圾回收的影响尽管方法区不属于堆内存但

JVM

仍然对方法区的内存进行管理并且可以对无用的类信息进行垃圾回收。

堆Heap

堆是所有线程共享的。

每个线程都可以访问堆中的对象多个线程也可能同时操作堆中的相同对象。

JVM

堆由垃圾回收器Garbage

负责清理无用对象、回收内存空间从而使得开发人员不需要手动管理内存。

堆内存通常会被划分为多个区域用于更高效的内存管理和垃圾回收策略。

典型的划分方式如下

年轻代Young

年轻代主要用于存放新创建的对象大多数的对象在这里分配内存。

年轻代的回收频率较高垃圾回收通常使用的是Minor

Eden

仍未被回收的对象。

相比于年轻代老年代的垃圾回收频率较低但执行的是Full

GC且

-Xms设置堆的初始大小。

-Xmx设置堆的最大大小。

-XX:NewRatio设置年轻代与老年代的比例。

-XX:SurvivorRatio设置

Eden

区的比例。

-XX:MaxMetaspaceSize设置元空间的最大大小Java

对象创建

是对整个堆年轻代和老年代进行垃圾回收回收那些不再被引用的对象。

这是一个相对耗时的操作可能会导致应用暂停即STWStop-The-World所以

Full

方法的执行存储方法调用时的局部变量、操作数栈、动态链接、方法出口等。

每个线程都有自己独立的虚拟机栈因此线程之间的栈空间是不共享的。

栈帧Stack

Frame的每个方法在执行时都会创建一个栈帧。

每个线程的虚拟机栈由多个

Java

会将栈帧压入当前线程的虚拟机栈。

当方法执行完成后对应的栈帧会从栈中弹出。

栈帧主要包括

局部变量表存储方法的局部变量包括方法参数和在方法体内定义的变量。

是一组用于存放方法参数和局部变量的数组以槽Slot为单位存储。

一个

Slot

Slot。

操作数栈用于方法执行中的各种临时数据存储是计算过程中的“工作区”。

在方法执行过程中用来存放中间计算的结果和参与运算的操作数。

类似于一个后进先出的栈。

操作数栈的大小是在编译期间确定的每个栈帧的操作数栈容量也由编译器确定。

动态链接用于支持方法调用时的动态连接每个栈帧中包含了一个指向当前方法所属的类的运行时常量池的引用。

这个引用用于实现

方法调用

时的动态连接具体来说是将常量池中的符号引用转换为方法的实际调用地址。

方法返回地址用来存放方法执行完毕后需要返回的地址以便于返回到上一个栈帧继续执行。

线程私有每个线程在创建时都会创建一个虚拟机栈。

栈是线程私有的不会在线程之间共享。

栈的生命周期与线程一致线程创建时分配虚拟机栈线程结束时虚拟机栈也会被销毁。

栈的大小虚拟机栈的大小可以通过

JVM

MB。

栈的大小影响到线程的深度即一个线程可以调用多少次方法特别是递归调用的深度。

StackOverflowError当线程的调用深度超过虚拟机栈的限制时会抛出该异常。

通常是因为方法调用过深例如递归方法没有合适的退出条件。

因此需要合理设置虚拟机栈的大小。

程序计数器PC

寄存器是每个线程私有的一个小内存区域它记录了当前线程执行的字节码指令的地址。

由于

JVM

是多线程的每个线程都需要独立执行自己的指令因此每个线程都有一个独立的程序计数器。

它的主要作用是在线程切换时能够恢复到正确的执行位置。

记录当前线程执行的字节码指令地址程序计数器用来存放当前线程正在执行的

字节码指令的地址每当一条字节码指令被执行完程序计数器会更新为下一条即将执行的指令地址。

支持线程切换JVM

时间片轮转

的方式进行线程切换。

为了保证线程恢复后可以继续正确执行代码每个线程都有自己的程序计数器。

当线程切换时当前线程的执行状态包括程序计数器的值会被保存切换回来时可以从该位置继续执行。

处理

Java

Method程序计数器则为空undefined因为本地方法不通过字节码执行。

线程私有每个线程都有自己独立的程序计数器彼此之间不共享。

生命周期与线程一致程序计数器的生命周期与线程相同线程创建时分配线程结束时销毁。

唯一一个不会出现

OutOfMemoryError

的区域与其他内存区域如堆、方法区、栈不同程序计数器是一个非常小的区域它不会发生内存溢出。

线程隔离程序计数器为每个线程提供了独立的指令记录机制这对于多线程并发执行至关重要确保每个线程能够独立执行自己的代码而不影响其他线程。

线程调度的支持程序计数器为线程调度提供了支持当发生线程切换时程序计数器记录了线程执行的具体位置能够在线程恢复时继续从正确的位置执行。

本地方法栈Native

Methods提供支持的内存区域。

本地方法是使用其他编程语言如

C编写的代码这些代码可以直接与底层操作系统或硬件进行交互通常通过

JNIJava

代码。

线程私有每个线程都有自己的本地方法栈。

栈溢出异常可能抛出

StackOverflowError

栈合并。

生命周期与线程相同本地方法栈的生命周期与线程一致在线程创建时分配线程结束时销毁。

本地方法栈与

虚拟机栈类似但它为调用本地方法服务。

它主要负责管理本地方法的调用状态和执行。

其作用包括

存储本地方法执行的上下文在执行本地方法时本地方法栈存储相关的局部变量和执行状态。

与

JNI

代码本地方法栈在这其中负责管理与本地代码交互的细节。

桥接底层系统资源通过本地方法Java

程序可以调用操作系统提供的底层资源如文件系统、网络设备、图形界面等。

本地方法栈与

用于管理本地方法的执行执行本地方法时本地方法栈记录本地方法的执行状态和局部变量。

对于调用本地代码的场景JVM

StackOverflowError当本地方法栈的调用层次过深栈空间不足时会抛出此异常。

这个与

JVM

类似通常出现在递归调用或大量本地方法调用的情况下。

OutOfMemoryError如果本地方法栈无法申请到足够的内存JVM

会抛出

OutOfMemoryError。

这种情况通常是在栈的初始大小设置过小或系统内存不足时发生。

JVM

切换到本地方法栈将控制权交给本地方法栈负责管理本地方法的调用状态。

调用结束后返回到虚拟机栈继续执行

Java

加载本地方法库System.loadLibrary(NativeLib);}public

static

NativeMethodExample();example.nativeMethod();

调用本地方法}

实现可能略有不同。

通过合理的参数调整可以避免内存不足或栈溢出异常。

垃圾回收算法和垃圾回收器

CollectionGC是自动管理内存的机制旨在回收不再使用的对象释放内存资源。

Java

提供了多种垃圾回收算法和垃圾回收器以适应不同的应用场景和需求。

垃圾回收算法

标记阶段从根对象开始遍历所有可达对象并标记它们。

清除阶段扫描整个堆回收未被标记的对象。

优点简单有效能够处理对象的循环引用。

缺点清理后会产生内存碎片可能导致后续的内存分配失败。

标记-整理算法Mark-Compact

原理与标记-清除算法类似但在清除阶段会整理存活对象将它们移动到堆的一端并更新引用地址。

优点避免了内存碎片问题适合老年代。

缺点移动对象需要更新引用开销较大。

复制算法Copying

原理将存活的对象从一块内存区域源区复制到另一块内存区域目标区清理源区。

优点高效地回收内存没有内存碎片。

缺点需要分配两块内存适用于年轻代且内存利用率较低通常只用到一半。

分代收集算法Generational

原理基于对象生命周期的特点将堆分为年轻代和老年代。

年轻代中的对象经过多次垃圾回收后晋升到老年代。

优点提高了垃圾回收的效率因为大多数对象都是短生命周期的。

缺点需要处理对象晋升的逻辑复杂度略高。

JVM

时会暂停所有应用线程STWStop-The-World适合单处理器系统。

适用场景适用于小型应用或内存较小的应用。

Parallel

类型多线程的垃圾回收器。

特点通过多线程并行进行垃圾回收适合多核处理器系统。

可以通过参数调整并行度。

适用场景适用于高吞吐量的应用。

CMSConcurrent

是针对老年代的回收器分为四个阶段初始标记STW、并发标记、重新标记STW和并发清除。

年轻代使用

复制算法

类型并发标记清除垃圾回收器。

特点在垃圾回收过程中应用线程仍然可以运行。

分为标记阶段和清除阶段后续执行部分工作与应用线程并发进行。

适用场景适合对响应时间敏感的应用但可能导致内存碎片。

G1Garbage-FirstGC

将堆分为多个区域Region每个区域可以存放年轻代或老年代对象。

对年轻代使用

Full

类型分代垃圾回收器。

特点将堆划分为多个区域Region优先回收垃圾最多的区域。

适用于大内存应用支持并行和并发回收。

适用场景适合低延迟和大内存的应用能够提供可预测的暂停时间。

ZGCZ

Pointers来标记对象的状态进行内存整理时对象会重新定位到新的内存区域。

Shenandoah

也将堆划分为多个区域但它的目的是在最短的时间内回收任何区域的内存。

Shenandoah

类型低延迟垃圾回收器类似

Root垃圾回收根对象是垃圾回收器进行内存管理的重要起点任何从

Root

描述方法执行时局部变量表中的所有引用类型变量局部变量、方法参数等都可以作为

Root。

实例当方法调用时局部变量表中的对象引用始终可达JVM

public

修饰的变量会随着类的加载进入方法区并且静态变量会一直存在于内存中直到类被卸载。

因此所有的静态变量也是

public

内部的一些系统级对象如类加载器ClassLoader等也可以作为

JMX

每个对象都维护一个引用计数器当有一个地方引用该对象时计数器加一当引用失效时计数器减一。

当计数器的值为零时说明该对象不再被引用系统就会认为它是垃圾可以被回收。

实现简单效率较高能快速判断对象是否可以被回收。

循环引用问题如果两个对象互相引用形成循环依赖它们的引用计数器不会为零即使它们都无法被访问引用计数法也无法回收它们。

Analysis

采用可达性分析算法来判断对象是否可以被回收。

这个方法从一组称为

Roots

的根对象开始沿着引用链进行遍历能够到达的对象被认为是“存活”的无法到达的对象被认为是不可达的可以被回收。

如果某个对象在从

Root

的引用路径上是不可达的说明它可以被回收。

没有循环引用问题因为是通过可达性分析来判断对象是否可以回收循环引用不会影响对象的回收。

更加准确现代垃圾回收器大多基于这种方法。

引用类型

这是最常见的引用类型。

通过正常的赋值创建的引用只要有强引用指向一个对象垃圾回收器就不会回收该对象。

Object

垃圾回收强引用所指向的对象在任何情况下都不会被垃圾回收。

只有当引用失效时垃圾回收器才会考虑回收这个对象。

如果一个对象被强引用所引用即使内存不足JVM

适用场景强引用适用于对必须存在的对象进行引用比如大多数普通对象的引用方式。

软引用Soft

用于描述一些还有用但并非必需的对象内存不足时会回收这些对象。

软引用可以通过

SoftReference

发现内存不足时会回收软引用指向的对象避免内存溢出OOM。

软引用常用于实现内存敏感的缓存。

例如缓存中存储的数据在内存充足时保留当内存不足时进行回收。

适用场景适用于缓存设计。

当系统内存充足时缓存数据不会被回收但在内存不足时缓存数据会被回收以避免

弱引用Weak

垃圾回收无论内存是否充足垃圾回收器在进行可达性分析时只要发现对象只被弱引用所引用便会立即回收该对象。

弱引用通常用于实现规范化映射canonicalizing

mappings例如

适用场景适用于那些希望对象在不被强引用时可以随时被回收的场景比如弱引用缓存避免对象长时间占用内存。

虚引用Phantom

最弱的引用不能通过虚引用获取对象实例唯一的作用是能在对象被回收时收到系统通知。

虚引用可以通过

PhantomReference

referenceQueue);特点垃圾回收虚引用的存在主要用于跟踪对象的生命周期它不能阻止对象被回收。

与虚引用关联的对象在垃圾回收时被标记为可回收回收之前会将虚引用对象加入到一个

ReferenceQueue

联合使用主要用于在对象被回收时进行一些后续处理比如资源释放。

适用场景虚引用适用于管理直接内存的回收、监控对象生命周期或执行对象销毁前的清理工作。

例如当使用

DirectByteBuffer

快很多主要是因为两者在内存区域、回收对象的数量、算法复杂度等方面存在本质上的区别。

Young

GC回收新生代的短命对象大多数对象在创建后很快就会被回收。

新生代的区域较小通常只包含一些存活时间较短的对象所以回收的时间较短。

Full

会回收整个堆中的所有对象包括长寿命的对象这些对象通常分布在老年代。

老年代区域较大回收时需要扫描和处理的对象更多涉及到的区域更广。

Young

区后很快就会变成垃圾。

由于新生代的大部分对象都可以很快被回收存活对象较少因此

Young

中除了新生代的对象外老年代中的长生命周期对象也需要被回收。

由于老年代中存放了很多长期存活的对象甚至包括存活了多个

周期的对象需要花费更多时间去检查这些对象是否可以被回收。

老年代的对象比较多、比较稳定垃圾回收的复杂度也更高。

Young

区。

复制算法的特点是简单、高效只需要扫描存活的对象未存活的对象直接被清除因此回收速度很快。

Full

GC老年代通常采用的是标记-清除算法Mark-Sweep或标记-整理算法Mark-Compact。

这些算法首先需要标记出所有的存活对象然后再执行清除或整理。

相比复制算法标记-清除和标记-整理算法的执行过程复杂得多尤其是标记和整理阶段会导致

Full

GC但因为新生代回收的是短命对象并且区域小所以尽管频繁发生单次执行的时间较短。

Full

GCFull

GC停顿时间较短因为回收的新生代区域较小存活的对象少复制算法效率高。

Full

GC停顿时间较长回收整个堆内存尤其是涉及到标记和整理阶段老年代中对象的数量和生命周期都较长导致停顿时间长。

内存整理Compaction

中不存在内存碎片的问题。

新生代中没有使用的内存会被连续的清理和整理。

Full

GC老年代在标记-清除算法后可能会产生内存碎片。

如果老年代存在内存碎片则需要进行内存整理Compaction这会导致回收耗时增加。

内存碎片会影响大对象的分配因为即使有足够的总内存但由于碎片化可能没有足够连续的空间来存储大对象。

Minor

会检查新生代中的对象回收那些不再使用的短生命周期对象。

手动调用虽然不推荐但可以通过

System.gc()

应用程序性能和稳定性的重要步骤。

调优的目标通常是减少垃圾回收的时间、降低内存使用和提高应用程序的吞吐量。

以下是一些常见的

JVM

选择合适的垃圾收集器具体命令如上调整堆内存大小通过调整堆内存的大小可以控制应用程序的性能。

设置初始堆大小-Xms512m设置最大堆大小-Xmx2048m设置年轻代大小-Xmn256m一般推荐将初始堆和最大堆的比值设置为

1:2

Recorder这是一个强大的性能监控工具可以提供深入的性能分析。

减少对象创建尽量复用对象避免频繁创建短命对象。

使用合适的数据结构选择合适的集合类例如

ArrayList

LinkedList并根据需求选择合适的实现。

避免内存泄漏定期检查代码中是否存在内存泄漏例如未清理的缓存、静态集合中的对象引用等。

设置最大线程数取决于应用和服务器的具体情况。

-XX:ParallelGCThreads4

设置并行

之后类元数据存储在本地内存中避免了旧版本中永久代的限制。

可以通过设置

Metaspace

测试与迭代调优是一个迭代过程。

在生产环境中测试是非常重要的步骤

负载测试在类似生产环境中进行负载测试以观察系统在高负载情况下的表现。

逐步调整每次只调整一个参数观察性能变化再进行下一步调整。

Full

问题是确保系统稳定性和性能的关键步骤。

以下是一些有效的排查方法和工具

日志启用

(MAT)可以帮助分析堆转储文件找出内存泄漏和长生命周期对象。

生成堆转储jmap

-dump:live,formatb,fileheapdump.hprof

然后使用

检查对象生命周期通过分析代码检查是否存在内存泄漏的情况可能导致

Full

静态集合检查是否有静态集合中引用的对象未被清理。

长生命周期对象分析老年代中存活的对象找出那些不再使用的对象。

应用程序代码优化

减少对象创建避免频繁创建短命对象。

使用合适的数据结构根据需要选择合适的集合类。

测试与调整

垃圾收集的行为包括垃圾回收频率、持续时间、回收的内存大小、各代新生代、老年代、元空间等的变化情况等。

通过以下

JVM

-XX:PrintGCApplicationStoppedTime

-Xloggc:gc.log

secs]时间戳2024-10-11T15:30:24.1230000

表示从

频繁发生可能是老年代空间不足或碎片化严重。

可以通过增大老年代空间或优化对象的生命周期来减少

Full

-XX:ParallelGCThreads或调整垃圾收集器类型如使用

栈日志

Logs是用于记录线程执行过程中的方法调用栈信息的日志文件。

栈日志通常在出现异常或错误时生成并为开发人员和运维人员提供调试和问题诊断的依据。

通过分析栈日志可以了解线程的执行路径、方法调用的顺序、异常发生的位置等信息从而定位性能瓶颈、线程问题或代码缺陷。

栈日志的主要作用是帮助开发者和运维人员分析和解决以下问题

异常定位当

NullPointerException、ArrayIndexOutOfBoundsException

等时会生成栈日志描述从异常发生点到当前方法调用栈的完整路径。

这可以帮助开发者快速定位问题的根源。

Exception

java.lang.NullPointerExceptionat

com.example.MyClass.myMethod(MyClass.java:10)at

com.example.MyClass.main(MyClass.java:5)通过栈日志可以看到

NullPointerException

线程状态分析栈日志可以显示每个线程当前的状态如运行、等待、阻塞等帮助分析线程问题。

例如通过线程栈信息可以发现死锁、线程饥饿、线程阻塞等问题。

Thread-1

[0x00007f8c9b500000]java.lang.Thread.State:

BLOCKED

com.example.MyClass.synchronizedMethod(MyClass.java:20)-

waiting

使用率过高或方法调用栈过深出现时通过分析栈日志可以发现哪个方法或代码段占用了过多的资源。

内存泄漏定位栈日志在处理内存泄漏问题时也很有帮助。

通过

OutOfMemoryError

相关的栈日志可以发现哪些对象没有被正确释放或在哪些地方频繁分配内存。

Exception

com.example.MyClass.allocateMemory(MyClass.java:25)at

com.example.MyClass.main(MyClass.java:10)这里显示

OutOfMemoryError

检测到死锁栈日志会显示参与死锁的线程信息。

显式打印栈信息可以通过程序显式地调用

Thread.dumpStack()

JVisualVM、JProfiler可以生成线程的栈信息用于性能调优和分析。

等。

方法调用栈记录每个方法的调用顺序包括类名、方法名和行号。

锁信息如果线程被阻塞或等待锁栈日志中会包含锁相关的信息。

main

[0x00007f8c9b507000]java.lang.Thread.State:

RUNNABLEat

java.io.FileInputStream.readBytes(Native

Method)at

java.io.FileInputStream.read(FileInputStream.java:233)at

java.io.BufferedInputStream.fill(BufferedInputStream.java:246)at

java.io.BufferedInputStream.read1(BufferedInputStream.java:286)at

java.io.BufferedInputStream.read(BufferedInputStream.java:345)at

sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)at

sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)at

sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)at

java.io.InputStreamReader.read(InputStreamReader.java:184)at

java.io.BufferedReader.fill(BufferedReader.java:161)at

java.io.BufferedReader.readLine(BufferedReader.java:324)at

java.io.BufferedReader.readLine(BufferedReader.java:389)at

com.example.MyClass.readFile(MyClass.java:35)at

com.example.MyClass.main(MyClass.java:20)线程的状态可以帮助确定线程当前的执行情况。

栈日志中的线程状态通常包括

RUNNABLE线程正在运行或等待

时间片。

BLOCKED线程被阻塞等待获取某个锁。

WAITING线程在等待其他线程的通知例如通过

Object.wait()

Thread.join()。

TIMED_WAITING线程在等待一定时间例如

Thread.sleep()

wait()、join()。

TERMINATED线程已经结束。

如何分析线程状态

问题某些线程长时间持有锁导致其他线程无法继续执行。

如果线程处于

WAITING

死锁通常表现为多个线程互相等待彼此持有的锁导致线程无法继续执行。

栈日志中的死锁信息通常表现为

“waiting

[0x00007f8c9b500000]java.lang.Thread.State:

BLOCKED

com.example.MyClass.method1(MyClass.java:20)-

waiting

[0x00007f8c9b507000]java.lang.Thread.State:

BLOCKED

com.example.MyClass.method2(MyClass.java:30)-

waiting

java.lang.Object)锁争用是性能问题的常见来源当多个线程争夺同一个锁时可能会导致线程阻塞降低系统的并发性能。

栈日志中的锁争用信息通常显示为

线程处于

[0x00007f8c9b500000]java.lang.Thread.State:

BLOCKED

com.example.MyClass.synchronizedMethod(MyClass.java:40)-

waiting

com.example.MyClass.synchronizedMethod(MyClass.java:40)-

locked

java.lang.Object)在这个例子中Thread-3

被阻塞等待

释放锁。

在实际生产环境中如果发现多个线程被长时间阻塞可以通过栈日志找到持有锁的线程从而优化锁的使用减少争用。

WAITING

有成百上千的线程在栈日志中可能是由于线程池配置不当或没有及时销毁线程。

线程的栈信息重复表明某些线程在进行重复的任务。

这种情况下可以考虑减少线程池的最大线程数或者更高效地使用异步任务。

JVM

[0x00007f8c9b500000]java.lang.Thread.State:

RUNNABLEat

com.example.MyClass.compute(MyClass.java:50)at

com.example.MyClass.main(MyClass.java:10)如何有效地分析

JVM

状态。

线程的状态信息是栈日志分析的关键。

检查锁争用情况如果线程被阻塞检查是否有锁争用问题锁的使用是否合理锁等待时间是否过长。

定位异常如果程序抛出异常如

NullPointerException、OutOfMemoryError

等通过栈日志定位异常发生的位置确定异常的原因。

检查线程数量观察是否有过多的线程创建线程数是否超过合理的范围。

结合上下文分析栈日志分析不应孤立进行结合应用的运行环境如

CPU、内存使用情况、I/O