Synchronized 的原理

Synchronized 修饰方法块

JVM 对方法块同步是通过 monitorenter 和 monitorexit 两个比较重要的指令来实现的。任何对象都有一个 monitor（这里 monitor 指的就是锁） 与之关联，当且仅当一个 monitor 被持有后，它将处于锁定状态。

ZGC 是 Oracle 内部研发的一款新的垃圾回收器，最大的宣传点是低延迟（Low Latency）。根据近期的消息，该项目将会托管给 OpenJDK，由后者开发完善。

ZGC 特性一览

ZGC 的设计目标

• TB 级别的堆内存管理；
• 最大 GC Pause 不高于 10ms；
• 最大的吞吐率（Throughput）损耗不高于 **15%**；

关键点：GC Pause 不会随着 堆大小的增加 而增大。

类加载概述

概述

定义：虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的java类型。类加载和连接的过程都是在运行期间完成的。

类加载分为 加载（Loading）、验证（Verfication）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）、卸载（Unloading） 这 7 个阶段。

这里总结一下在 Java 服务中，常见的 内存溢出（OutOfMemoryError）问题及解决思路。

堆溢出

报错信息：java.lang.OutOfMemoryError: Java heap space

原因

1. 堆中（新生代和老年代）无法继续分配对象了；
2. 某些对象的引用长期被持有没有被释放，垃圾回收器无法回收；
3. 使用了大量的 Finalizer 对象，这些对象并不在 GC 的回收周期内。

解决方法

CMS(Concurrent-Mark-Sweep)是 Hotspot 虚拟机中目前使用最广泛的老年代垃圾回收器，在响应时间这个GC 指标上表现优异。CMS 在什么时机开始工作？触发的条件都有哪些？今天我们可以从 OpenJDK 中 CMS 这一块的实现来分析一下，该实现主要位于concurrentMarkSweepGeneration 和 ConcurrentMarkThread 这两个类中。

Java和C++之间有一堵由内存分配和垃圾回收技术所围成的高墙，在里面的人想出来，不在里面的人想进去。C++程序员必须承担每一个对象生命开始到终结的责任，而Java程序员无须为每一个new 出来的对象执行 delete/free 操作，不容易出现内存泄漏和内存溢出问题。

背景

在GC日志里，一条完整的GC日志记录最后，会带有本次GC所花费的时间，如下面这一条新生代GC：

[GC [DefNew: 3298K->149K(5504K), 0.0053498 secs] 3298K->3221K(9600K), 0.0053750 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]

注意到日志中时间分为了三块：user， sys，和 real，三者的区别和含义如下：

• real：指的是在此次GC事件中所花费的总时间；
• user：指的是CPU工作在用户态所花费的时间；
• sys：指的是CPU工作在内核态所花费的时间。

常用命令

1. jstat -gc pid
2. jstat -gccapacity pid
3. jstat -gcutil pid
4. jstat -gcnew pid
5. jstat -gcnewcapacity pid
6. jstat -gcold pid
7. jstat -gcoldcapacity pid
8. jstat -gcpermcapacity pid
9. jstat -class pid
10. jstat -compiler pid
11. jstat -printcompilation pid