Java性能权威指南（第2版）读后总结与感想

Posted 2023-04-08 躺柒

1. 基本信息

Java性能权威指南（第2版） Java Performance,Second Edition

[美]斯科特·奥克斯（Scott Oaks）

人民邮电出版社,2022年4月出版

1.1. 读薄率

书籍总字数516千字，笔记总字数43820字。

读薄率43820÷516000≈8.49%

1.2. 读厚方向

1. Java性能优化实践 JVM调优策略 工具与技巧

2. Java技术手册（原书第7版）

3. Learning Java Functional Programming

4. Functional C#

5. Functional Programming in C#

1.3. 笔记--章节对应关系

笔记	章节	字数
读Java性能权威指南（第2版）笔记01_导言	第01章导论	740
读Java性能权威指南（第2版）笔记02_JavaSEAPI技巧上	第12章Java SE API技巧	1366
读Java性能权威指南（第2版）笔记03_JavaSEAPI技巧中		1247
读Java性能权威指南（第2版）笔记04_JavaSEAPI技巧下		1350
读Java性能权威指南（第2版）笔记05_数据库性能JDBC	第11章数据库性能最佳实践	2275
读Java性能权威指南（第2版）笔记06_数据库性能JPA&SpringData		1980
读Java性能权威指南（第2版）笔记07_即时编译器上	第04章使用即时编译器	1492
读Java性能权威指南（第2版）笔记08_即时编译器中		1234
读Java性能权威指南（第2版）笔记09_即时编译器下		1221
读Java性能权威指南（第2版）笔记10_原生内存	第08章原生内存最佳实践	1284
读Java性能权威指南（第2版）笔记11_堆内存上	第07章堆内存最佳实践	1463
读Java性能权威指南（第2版）笔记12_堆内存中		985
读Java性能权威指南（第2版）笔记13_堆内存下		2277
读Java性能权威指南（第2版）笔记14_垃圾回收A	第05章垃圾回收简介	1441
读Java性能权威指南（第2版）笔记15_垃圾回收B		1225
读Java性能权威指南（第2版）笔记16_垃圾回收C		1282
读Java性能权威指南（第2版）笔记17_垃圾回收D		1428
读Java性能权威指南（第2版）笔记18_垃圾回收E	第06章垃圾回收算法	1943
读Java性能权威指南（第2版）笔记19_垃圾回收F		2370
读Java性能权威指南（第2版）笔记20_垃圾回收G		1261
读Java性能权威指南（第2版）笔记21_垃圾回收H		858
读Java性能权威指南（第2版）笔记22_ 操作系统工具和Java监控工具	第03章Java性能工具箱	1552
读Java性能权威指南（第2版）笔记23_ 性能分析工具		897
读Java性能权威指南（第2版）笔记24_ Java飞行记录器JFR		1283
读Java性能权威指南（第2版）笔记25_ 性能测试方法上	第02章性能测试方法	1253
读Java性能权威指南（第2版）笔记26_ 性能测试方法下		988
读Java性能权威指南（第2版）笔记27_线程和同步性能上	第09章线程和同步性能	1772
读Java性能权威指南（第2版）笔记28_线程和同步性能中		2434
读Java性能权威指南（第2版）笔记29_线程和同步性能下		1215
读Java性能权威指南（第2版）笔记30_Java服务器	第10章Java服务器	1704
	总计	43820

2. 亮点

2.1. 垃圾回收和内存方面讲解细致

在垃圾回收、原生内存和堆内存方面讲解相对细致，涉及各种开关。

2.2. 不断进化的垃圾回收算法

语言在不断进化发展、jvm也在不断进化发展，在采用java 8 不变的情况下，使用包含新的垃圾回收算法的jdk，使用新的垃圾回收算法能够获得更好的性能体验。

2.3 验证、测试是必不可少的

有些性能建议是包治百病的，比如，使用更小的对象；有些性能建议则需要具体问题具体分析，验证、测试是必不可少的，

2.4 工欲善其事，必先利其器

验证、测试自然少不了各种工具，既有原生自带的，也有开源或者商业的第三方工具，在这个方面，介绍的也较详细，能够帮忙我们分析性能问题的源头。

3. 感想

3.1. 又一个好长啊

已经超越上一本书了，该书是目前更新时间最长、笔记字数最多的一本书了。自己回头看，笔记都写了4.3W字啊。

3.2 博大精深

了解不难，学精很难，性能调优不仅仅是技术活，更是一门艺术，需要考虑的场景、判断的条件纷繁复杂，各种开关也会相互影响，使用的不好，还不如采用默认方式。

套用函数式编程的思维，屏蔽这些复杂性，让jvm去选择最好的方式。

专心算法层面优化，或者业务流程重组带来的效率提升。

毕竟，jvm再快，也无法改变DB或者IO方面的慢，又或者是低效的业务流程。

3.3. 经典书籍，推荐阅读

读Java性能权威指南（第2版）笔记23_ 性能分析工具

1. 性能分析工具

1.1. 必须有足够大的堆来处理数据

1.2. 运行性能分析工具时开启并发GC算法

1.3. 不合时宜的Full GC暂停会导致缓冲区的数据溢出

1.4. 性能分析的一个缺陷就是在应用程序中引入测试会改变其性能

1.5. 在工作时要“附加”到被分析的应用程序上

• 1.5.1. 通过socket或者被称为JVM工具接口（JVM Tool Interface，JVMTI）的原生Java接口进行的

• 1.5.2. 目标应用程序和性能分析工具开始交换关于目标应用程序行为的信息

2. 采样分析器

2.1. 性能分析的基本模式

2.2. 想要减小误差，就要延长采样周期并减小采样间隔

2.3. 安全点偏差（safepoint bias）

• 2.3.1. 只有在线程到安全点之后才可以获取线程的栈轨迹（stack trace）

2.4. 线程自动进入安全点场景

• 2.4.1. 在同步锁上阻塞

• 2.4.2. 等待I/O时阻塞

• 2.4.3. 等待管程时阻塞

• 2.4.4. 线程挂起

• 2.4.5. 正在执行Java本地接口（Java Native Interface，JNI）代码（执行GC锁定函数除外）

2.5. 异步分析器（async profiler）

• 2.5.1. JVM可以在任何时间点提供栈信息，而无须等待线程到达（同步）安全点

• 2.5.2. 通过AsyncGetCallTrace接口实现的

• 2.5.3. 异步接口在Java 8被公开，在此之前它是私有接口

• 2.5.4. 以异步方式收集栈信息的采样分析器引入的测量失真更小

2.6. 火焰图（flame graph）

• 2.6.1. 一个应用程序调用栈的交互式图表

• 2.6.2. 自底向上的图表

• 2.6.3. 开源项目async-profiler

2.7. 自顶向下的调用树（call tree）

3. 探查分析器

3.1. 相对于采样分析器更有侵入性

• 3.1.1. 会在类加载时更改字节码序列

3.2. 能提供更多关于应用程序内部正在发生什么的有益信息

3.3. 更可能在应用程序中引入性能偏差

• 3.3.1. 编译器是基于代码的大小来决定是否内联的，而根据代码探查的方式，方法可能不再符合内联的条件

3.4. 最好用于二级分析

• 3.4.1. 采样分析器将性能问题指向某个包或某段代码，然后探查分析器在需要时深入研究此代码

• 3.4.2. 用于探查一小部分代码——几个类或包

4. 阻塞方法和线程时间线

4.1. 要知道线程阻塞是不是性能问题的原因，需要检查它们为什么被阻塞

4.2. 通过正在阻塞的方法或者线程时间线分析，可以分辨阻塞的线程

5. 原生分析器

5.1. async-profiler和Oracle Developer Studio的工具

5.2. 可以提供JVM代码和应用程序代码的内部运行信息

5.3. 如果原生分析器显示主要占用CPU资源的是GC时间，那么优化垃圾回收器是正确的选择

5.4. 如果它显示编译线程占用大量时间，那么这通常不会影响应用程序的性能