java每秒执行一次_Java性能权威指南

[2020年5月15日]开坑。左右看看，可能这本书更加适合作为休息读物，不要求连续花长时间去理解内容，更加偏实践。书中示例代码：https://github.com/scottoaks/javaperformancetuning[2020年5月17日]第1章导论概述本书涉及的知识主要分两类。1. 如何对Java虚拟机自身的性能进行调优，即如何通过jvm的配置来影响程序的各种性能指标；2. 理解J

weixin_39603505

1792人浏览 · 2021-01-21 15:31:56

weixin_39603505 · 2021-01-21 15:31:56 发布

[2020年5月15日]

开坑。左右看看，可能这本书更加适合作为休息读物，不要求连续花长时间去理解内容，更加偏实践。

书中示例代码：https://github.com/scottoaks/javaperformancetuning

[2020年5月17日]

第1章导论

概述

本书涉及的知识主要分两类。1. 如何对Java虚拟机自身的性能进行调优，即如何通过jvm的配置来影响程序的各种性能指标；2. 理解Java平台的特性对性能影响，包括Java语言（线程、同步等）和Java标准api（例如解析XML 性能）

jvm调优标志

JVM 主要接受2类调优标志：布尔标志和附带参数的标志。

布尔标志采用如下语法：-XX:+FlagName 表示开启， -XX:-FlagName表示关闭。

附带参数的标志采用以下语法：-XX:FlagName=value, 表示将FlagName的值设置为value。

全面的性能调优

编写更好的算法
编写更少的代码
避免过早优化（复杂的过早优化）
数据库可能就是瓶颈，Java访问的外部资源可能就是瓶颈。

[2020年5月20日]

第2章性能测试方法主要讨论了4条性能测试的原则。

原则1：测试真实的应用：在实际使用的场景中测试性能。性能测试分微基准测试、宏基准测试、介基准测试3种，各有优劣，选择适用于实际应用的才能取得最好的效果。

微基准测试：测试微小代码单元的性能，如同步、非同步比较，线程创建与线程池使用的代价比较等。需要注意的是，所测单元的代码需要实际执行，而不能因为编译优化导致被测代码并为执行，如下例子：

public void doTest(){
    double l;
    long then=System.currentTimeMills();
    for(int i=0;i<nLoops;i++){
        l=fibnacci(50);
    }
    long now=System.currentTimeMills();
    System.out.println("time: "(now-then)/1000);
}

这段代码被编译优化后，如下

public void doTest(){
    double l;
    long then=System.currentTimeMills();
   long now=System.currentTimeMills();
    System.out.println("time: "(now-then)/1000);
}

因为它并为改变程序的任何状态。将局部变量 l 的定义改变为实例变量（并用volatile声明），就能测试这个方法的性能了。

使用合理的随机数，不要使用测试程序以外的测试数据，如要测试阶乘，却传入负数，使得程序抛出异常或者被if语句忽略。

尽量减少被测代码模块中的无效代码，如println等辅助函数的调用。

热身期问题：Java的一个特点是代码执行的越多性能越好。微基准测试需要热身期，否则测量的是编译代码而不是被测代码的性能。

宏基准测试：测试应用程序的整体性能，而非某一段代码。

介基准测试：测试某个功能某块的代码，如socket管理代码、读取请求模块代码等。

原则2：理解批处理时间、吞吐量、响应时间。

由于JIT（及时编译）的存在，研究Java性能优化需要关注热身期——在运行代码足够长的时间，已经编译且优化之后再测性能。

批处理关注的是，从处理开始到结束时整体的性能。某个批处理前段时间性能<后段时间，这种情况并无大碍。

吞吐量测试：基于一段时间内所能完成的工作量，常见指标，每秒事务数TPS，每秒请求数RPS，每秒操作数OPS。在客户端、服务端的测试中存在着“客户端不能足够快的向服务端发送数据”的问题。

响应时间：客户端从发送请求至接收到响应之间流逝的时间。衡量方法：平均值，或者百分位数（超过90%响应时间是多少）。

原则3：统计方法应对性能变化

由于测试数据的随机性、操作系统调度等原因，即使相同的代码，性能也会有差别。对于性能的差异，利用学生t检验、置信度、显著性等概念来比较测试结果。

因代码改变而进行的测试——回归测试。回归测试中，原来的代码成为基线代码（baseline）、新代码称为试样（specimen）。

原则4：尽早频繁测试

尽早开发、尽早测试。

自动化测试、测试一切（各种信息采集，如CPU使用率、磁盘使用率、网络使用率，内存使用率）、真实系统上运行。

第3章 Java性能调优工具箱

本章主要关注操作系统的性能分析工具和jdk提供的程序分析工具。

操作系统提供的工具包括：

CPU使用率：vmstat（virtual memory statistics）"vmstat 1" 每隔1s给出统计数据。CPU使用率表示程序以多高的效率使用CPU，所以数字越大，性能越好。man page 链接

CPU队列：vmstat 命令。如果试图运行的线程数超过了可用的CPU，性能就会下降。

性能检查时，首先应该审查CPU时间；优化代码的目的是提升而不是降低CPU使用率。

磁盘使用率：iostat（input/output statistics）"iostat -xm 2 6" 每隔2秒计算一次，计算6次，m表示结果按照megabite显示。 man page。

网络使用率：

* netstat 显示网络连接、routing table、网络接口统计数据、多播成员组；https://linux.die.net/man/8/netstat

* nicstat：打印网络traffic statistics。nicstat 5 每隔5s统计一次数据。区别带宽代码bps和其他使用单位Bps（字节每秒）https://docs.oracle.com/cd/E86824_01/html/E54763/nicstat-1.html

网络无法支持100%使用率，对于局域网来说，承受的网络使用率超过40%就意味着接口饱和了。

[2020年5月28日]

这一章主要介绍了Linux 系统性能监控工具（上面已经介绍）&&Java application&&JVM 性能监控工具（如下）以及一些优化思想。

java 性能监控工具：jcmd、jconsole、jhat、jmap、jinfo、jstack、jstat、jvisualvm。可以用man命令看如何使用。

这些工具的功能可以概括为：

基本VM信息
线程信息
类信息
实时GC分析
堆转储的事后处理
JVM性能分析

还介绍了采样分析与探查分析。重要思想方法：

所有性能分析必然对应用原来的性能产生影响。
采样分析可能发生严重偏差（采样点存在bias，比如两个线程交叉执行，每次采样都是threadB，由此得出threadB执行时间更长）
找到用时最长的系统性原因，而不是局限于某一个、几个用时最长的线程的优化

Java任务控制，jmc 命令，对Java程序有更精细的统计数据，但是需要在运行Java程序的时候添加启用jmc的标志。Java flight recorder JFR是jmc的核心特征。

[2020年6月10日]

之前看的是第4章 JIT 编译器。这一章主要介绍了JVM编译器以及优化执行相关知识。

JVM 有两种编译器类型、多种版本、三种编译类型
- client编译器（C1编译器）和server 编译器（C2编译器）
- 有32位、64位不同版本（和平台有关，并非所有编译器类型在各个寻址大小下都有）
- 仅使用client编译（只有在C1编译器下才有效，c2编译器上只能server编译），仅使用server编译（只能在C2编译器下进行），分层编译（先c1后c2，只能在C2编译器下进行）。Java8中默认开启分层编译。
  - client编译策略：编译开启时间早，在任务运行的早起开始阶段速度较快
  - server编译策略：编译开启的晚，在任务过了热身阶段之后，对热代码（高频执行的）编译优化，使得整个热身之后的执行速度都比client编译要快
  - 分层编译：早期使用client编译，之后使用server编译

编译优化基于两种JVM 计数器：方法调用计数器和方法中的循环回边计数器。方法计数器超过阈值，该方法被放入编译队列进行编译（这个编译与代码执行是异步的，这个过程一般叫做标准编译），在方法下次被调用时执行编译后的代码。循环回边计数器超过阈值，执行循环的代码也会被编译。这部分被编译的代码会替换还在栈上的代码（叫做栈上替换，Over Stack Replacement, OSR)，下次循环迭代时使用编译后的代码。

可用-XX:+PrintCompilation选项，每次编译一个方法或者循环时，JVM就会打印一行被编译的内容信息。jstat 也能检测编译器内部工作情况。

短小、被频繁调用的代码会被直接内联执行，代码内联是默认开启的。如getter、setter会被自动内联。

高级编译优化还包括：

逆优化
- 代码被弃置：新编译策略生成的代码会使得之前运行的代码被丢弃
- 逆向化僵尸代码：被弃置的类长期不被调用会被标记为僵尸代码，然后他们可以被从代码缓存中移除。
分层编译级别，共5种执行级别。client 编译器有3中级别
- 0：解释代码
- 1：简单C1编译代码
- 2：受限的C1编译代码
- 3：完全C1编译代码
- 4：C2编译代码

代码期望编译顺序为：级别0 --》 3--》4 。按照这个顺序性能可以达到最优。

当编译级别4中server队列满了，就会从server队列中取出方法，以级别2进行编译，C1编译器使用方法调用计数器和回边计数器。当方法的调用计数器达到阈值之后就被编译为级别3，最终当server 编译器队列不太忙的时候就被编译为级别4.

如果方法经常被编译为级别2，并且还有额外的可用CPU周期，那就可以考虑增加编译器线程数，从而减少server编译器队列的长度。

从调优的角度看，简单的选择就是对所有应用都使用server编译器和分层编译，能够解决90%与编译器相关的性能问题。

有没有final关键字，都不会影响应用的性能。

需要编译的代码在编译队列中，队列中代码越多，程序达到最佳性能时间越久。

[2020年6月21日]

近期主要看了 “第5章 JVM 垃圾收集入门”。

四个主流垃圾收集器：

Serial收集器（常用于单CPU）
Throughput（或者Parallel）收集器
CMS（concurrent 收集器）
G1收集器（concurrent收集器）

垃圾收集主要包含两步：

查找不再使用的对象（如果仅仅用“不再被引用”作为判定对象是否使用，会有问题。比如一个不再使用的循环链表，永远无法被释放）
释放这些对象占用的内存

逻辑上，JVM 线程分成两类：应用程序线程，垃圾收集器线程。垃圾回收时移动内存中的对象，此时需要确保应用程序线程不再继续使用这些对象。

时空停顿（stop-the-world）：所有应用线程停止。

所有GC算法都将老年代分成：

老年代
新生代
- Eden
- survivor

新生代是堆的一部分，对象首先在新生代分配。新生代填满时，垃圾收集器会暂停所有应用线程，回收新生代空间。不再使用的对象会被回收，仍然在使用的对象会被移动到其他地方，这种操作时Minor GC. 仍然使用的对象被移动到survivor空间或者老年代。所有算法对新生代进行垃圾回收时都存在“时空停顿”现象。

当老年代被填满时，JVM需要找出老年代中不再被使用的对象，并对它们进行回收。——对老年代的垃圾回收方法，是垃圾收集算法差异最大的地方。

Full GC：停掉所有应用线程，找出不再使用的对象进行回收，接着对堆空间进行整理。——导致较大的停顿。

CMS和G1收集器以消耗更多CPU为代价，在应用程序线程运行的时候找出不再使用的对象。但是他们也会遭遇长时间的Full GC停顿。

Java提供System.gc()来强制进行GC。

四种垃圾收集算法：

Serial收集器：常用语仅有单CPU可用以及其他程序会干扰GC的情况（通常是默认GC）
Throughput收集器：在其他虚拟机上是默认值，它能最大化应用程序的总吞吐量，但是有些操作可能遇到较长的停顿。
CMS收集器：能够在应用线程运行的同时并行地对老年代的垃圾进行收集。如果CPU的计算能力足以支撑后台垃圾收集线程的运行，该算法能够避免应用程序发送full gc
G1收集器：也能在应用程序运行的同时并发地对老年代的垃圾进行收集,在某种程度上能够减少发生full gc的风险.G1的设计理念使得它比CMS更不容易遭遇full gc。

使用Throughput收集器处理应用程序的批量任务能最大程度地利用CPU处理能力，通常能获得更好的性能。

如果批量任务并没有使用机器上所有可用的CPU资源，那么切换到concurrent收集器往往能够取得更好的性能。

CMS收集器和G1收集器之间的抉择：一般情况下，堆空间小于4GB时，CMS收集器的性能比G1收集器好。使用大型堆或者巨型堆时，由于G1收集器可以分割工作，通常它比CMS收集器表现得更好。（G1收集器将老年代划分成不同区域，使用更多的线程分担扫描老年代空间的任务）。

GC调优基础：