JVM优化+Tomcat优化
- Tomcat8的优化
- 看懂Java底层字节码
- 编码的优化建议
1、Tomcat8优化
tomcat服务器在JavaEE项目中使用率非常高,所以在生产环境对tomcat的优化也变得非常重要了。
对于tomcat的优化,主要是从2个方面入手,一是,tomcat自身的配置,另一个是tomcat所运行的jvm虚拟机的调优。
下面我们将从这2个方面进行讲解。
1.1、Tomcat配置优化
1.1.1、部署安装tomcat8
下载并安装:
https://tomcat.apache.org/download-80.cgi
1 | cd /tmp |
点击“Server Status”,输入用户名、密码进行登录,tomcat/tomcat
进入之后即可看到服务的信息。
1.1.2、禁用AJP连接
在服务状态页面中可以看到,默认状态下会启用AJP服务,并且占用8009端口。
什么是AJP呢?
AJP(Apache JServer Protocol)
AJPv13协议是面向包的。WEB服务器和Servlet容器通过TCP连接来交互;为了节省SOCKET创建的昂贵代价,WEB服务器会尝试维护一个永久TCP连接到servlet容器,并且在多个请求和响应周期过程会重用连接。
我们一般是使用Nginx+tomcat的架构,所以用不着AJP协议,所以把AJP连接器禁用。
修改conf下的server.xml文件,将AJP服务禁用掉即可。
1 | <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" /> |
重启tomcat,查看效果。
可以看到AJP服务以及不存在了。
1.1.3、执行器(线程池)
在tomcat中每一个用户请求都是一个线程,所以可以使用线程池提高性能。
修改server.xml文件:
1 | <!--将注释打开--> |
保存退出,重启tomcat,查看效果。
在页面中显示最大线程数为-1,这个是正常的,仅仅是显示的问题,实际使用的指定的值。
也有人遇到这样的问题:https://blog.csdn.net/weixin_38278878/article/details/80144397
1.1.4、3种运行模式
tomcat的运行模式有3种:
- bio
默认的模式,性能非常低下,没有经过任何优化处理和支持. - nio
nio(new I/O),是Java SE 1.4及后续版本提供的一种新的I/O操作方式(即java.nio包及其子包)。Java nio是一个基于缓冲区、并能提供非阻塞I/O操作的Java API,因此nio也被看成是non-blocking I/O的缩写。它拥有比传统I/O操作(bio)更好的并发运行性能。 - apr
安装起来最困难,但是从操作系统级别来解决异步的IO问题,大幅度的提高性能.
推荐使用nio,不过,在tomcat8中有最新的nio2,速度更快,建议使用nio2.
设置nio2:
1 | <Connector executor="tomcatThreadPool" port="8080" protocol="org.apache.coyote.http11.Http11Nio2Protocol" |
可以看到已经设置为nio2了。
1.2、部署测试用的java web项目
为了方便测试性能,我们将部署一个java web项目,这个项目本身和本套课程没有什么关系,仅仅用于测试。
注意:这里在测试时,我们使用一个新的tomcat,进行测试,后面再对其进行优化调整,再测试。
1.2.1、创建dashboard数据库
在资料中找到sql脚本文件dashboard.sql,在linux服务器上执行。
1 | cat dashboard.sql | mysql -uroot -proot |
创建完成后,可以看到有3张表。
1.2.2、部署web应用
在资料中找到itcat-dashboard-web.war,上传到linux服务器,进行部署安装。
1 | cd /tmp/apache-tomcat-8.5.34/webapps |
重新启动tomcat。
访问首页,查看是否已经启动成功:http://192.168.40.133:8080/index
1.3、使用Apache JMeter进行测试
Apache Jmeter是开源的压力测试工具,我们借助于此工具进行测试,将测试出tomcat的吞吐量等信息。
1.3.1、下载安装
下载地址:http://jmeter.apache.org/download_jmeter.cgi
安装:直接将下载好的zip压缩包进行解压即可。
进入bin目录,找到jmeter.bat文件,双机打开即可启动。
1.3.2、修改主题和语言
默认的主题是黑色风格的主题并且语言是英语,这样不太方便使用,所以需要修改下主题和中文语言。
主题修改完成。
接下来设置语言为简体中文。
语言修改完成。
1.3.3、创建首页的测试用例
第一步:保存测试用例
第二步:添加线程组,使用线程模拟用户的并发
1000个线程,每个线程循环10次,也就是tomcat会接收到10000个请求。
第三步:添加http请求
第四步:添加请求监控
1.3.4、启动、进行测试
1.3.5、聚合报告
在聚合报告中,重点看吞吐量。
1.4、调整tomcat参数进行优化
通过上面测试可以看出,tomcat在不做任何调整时,吞吐量为73次/秒。
1.4.1、禁用AJP服务
可以看到,禁用AJP服务后,吞吐量会有所提升。
当然了,测试不一定准确,需要多测试几次才能看出是否有提升。
1.4.2、设置线程池
通过设置线程池,调整线程池相关的参数进行测试tomcat的性能。
1.4.2.1、最大线程数为500,初始为50
1 | <Executor name="tomcatThreadPool" namePrefix="catalina-exec-" |
测试结果:
吞吐量为128次/秒,性能有所提升。
1.4.2.2、最大线程数为1000,初始为200
1 | <Executor name="tomcatThreadPool" namePrefix="catalina-exec-" |
吞吐量为151,性能有所提升。
1.4.2.3、最大线程数为5000,初始为1000
是否是线程数最多,速度越快呢? 我们来测试下。
1 | <Executor name="tomcatThreadPool" namePrefix="catalina-exec-" |
可以看到,虽然最大线程已经设置到5000,但是实际测试效果并不理想,并且平均的响应时间也边长了,所以单纯靠提升线程数量是不能一直得到性能提升的。
1.4.2.4、设置最大等待队列数
默认情况下,请求发送到tomcat,如果tomcat正忙,那么该请求会一直等待。这样虽然可以保证每个请求都能请求到,但是请求时间就会边长。
有些时候,我们也不一定要求请求一定等待,可以设置最大等待队列大小,如果超过就不等待了。这样虽然有些请求是失败的,但是请求时间会虽短。典型的应用:12306。
1 | <!--最大等待数为100--> |
测试结果:
- 平均响应时间:3.1秒
- 响应时间明显缩短
- 错误率:49.88%
- 错误率提升到一半,也可以理解,最大线程为500,测试的并发为1000
- 吞吐量:238次/秒
- 吞吐量明显提升
结论:响应时间、吞吐量这2个指标需要找到平衡才能达到更好的性能。
1.4.3、设置nio2的运行模式
将最大线程设置为500进行测试:
1 | <Executor name="tomcatThreadPool" namePrefix="catalina-exec-" |
可以看到,平均响应时间有缩短,吞吐量有提升,可以得出结论:nio2的性能要高于nio。
1.5、调整JVM参数进行优化
接下来,测试通过jvm参数进行优化,为了测试一致性,依然将最大线程数设置为500,启用nio2运行模式。
1.5.1、设置并行垃圾回收器
1 | 年轻代、老年代均使用并行收集器,初始堆内存64M,最大堆内存512M |
测试结果与默认的JVM参数结果接近。(执行了2次测试,结果是第二次测试的结果)
1.5.2、查看gc日志文件
将gc.log文件上传到gceasy.io查看gc中是否存在问题。
问题一:
在报告中显示,在5次GC时,系统所消耗的时间大于用户时间,这反应出的服务器的性能存在瓶颈,调度CPU等资源所消耗的时间要长一些。
问题二:
可以关键指标中可以看出,吞吐量表现不错,但是gc时,线程的暂停时间稍有点长。
问题三:
通过GC的统计可以看出:
- 年轻代的gc有74次,次数稍有多,说明年轻代设置的大小不合适需要调整
- FullGC有8次,说明堆内存的大小不合适,需要调整
问题四:
从GC原因的可以看出,年轻代大小设置不合理,导致了多次GC。
1.5.3、调整年轻代大小
1 | JAVA_OPTS="-XX:+UseParallelGC -XX:+UseParallelOldGC -Xms128m -Xmx1024m -XX:NewSize=64m -XX:MaxNewSize=256m -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:../logs/gc.log" |
将初始堆大小设置为128m,最大为1024m
初始年轻代大小64m,年轻代最大256m
从测试结果来看,吞吐量以及响应时间均有提升。
查看gc日志:
可以看到GC次数要明显减少,说明调整是有效的。
1.5.4、设置G1垃圾回收器
1 | 设置了最大停顿时间100毫秒,初始堆内存128m,最大堆内存1024m |
测试结果:
可以看到,吞吐量有所提升,评价响应时间也有所缩短。
1.5.5、小结
通过上述的测试,可以总结出,对tomcat性能优化就是需要不断的进行调整参数,然后测试结果,可能会调优也可能会调差,这时就需要借助于gc的可视化工具来看gc的情况。再帮我我们做出决策应该调整哪些参数。
2、JVM字节码
前面我们通过tomcat本身的参数以及jvm的参数对tomcat做了优化,其实要想将应用程序跑的更快、效率更高,除了对tomcat容器以及jvm优化外,应用程序代码本身如果写的效率不高的,那么也是不行的,所以,对于程序本身的优化也就很重要了。
对于程序本身的优化,可以借鉴很多前辈们的经验,但是有些时候,在从源码角度方面分析的话,不好鉴别出哪个效率高,如对字符串拼接的操作,是直接“+”号拼接效率高还是使用StringBuilder效率高?
这个时候,就需要通过查看编译好的class文件中字节码,就可以找到答案。
我们都知道,java编写应用,需要先通过javac命令编译成class文件,再通过jvm执行,jvm执行时是需要将class文件中的字节码载入到jvm进行运行的。
2.1、通过javap命令查看class文件的字节码内容
首先,看一个简单的Test1类的代码:
1 | package cn.itcast.jvm; |
通过javap命令查看class文件中的字节码内容:
1 | javap -v Test1.class > Test1.txt |
查看Test1.txt文件,内容如下:
1 | Classfile /F:/code/bestqiang-jvm/bestqiang-jvm-test/target/classes/cn/bestqiang/jvm/Test1.class |
内容大致分为4个部分:
第一部分:显示了生成这个class的java源文件、版本信息、生成时间等。
第二部分:显示了该类中所涉及到常量池,共35个常量。
第三部分:显示该类的构造器,编译器自动插入的。
第四部分:显示了main方的信息。(这个是需要我们重点关注的)
2.2、常量池
官网文档:
https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4-140
Constant Type | Value | 说明 |
---|---|---|
CONSTANT_Class |
7 | 类或接口的符号引用 |
CONSTANT_Fieldref |
9 | 字段的符号引用 |
CONSTANT_Methodref |
10 | 类中方法的符号引用 |
CONSTANT_InterfaceMethodref |
11 | 接口中方法的符号引用 |
CONSTANT_String |
8 | 字符串类型常量 |
CONSTANT_Integer |
3 | 整形常量 |
CONSTANT_Float |
4 | 浮点型常量 |
CONSTANT_Long |
5 | 长整型常量 |
CONSTANT_Double |
6 | 双精度浮点型常量 |
CONSTANT_NameAndType |
12 | 字段或方法的符号引用 |
CONSTANT_Utf8 |
1 | UTF-8编码的字符串 |
CONSTANT_MethodHandle |
15 | 表示方法句柄 |
CONSTANT_MethodType |
16 | 标志方法类型 |
CONSTANT_InvokeDynamic |
18 | 表示一个动态方法调用点 |
2.3、描述符
2.3.1、字段描述符
官网:https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.3.2
FieldType term | Type | Interpretation |
---|---|---|
B |
byte |
signed byte |
C |
char |
Unicode character code point in the Basic Multilingual Plane, encoded with UTF-16 |
D |
double |
double-precision floating-point value |
F |
float |
single-precision floating-point value |
I |
int |
integer |
J |
long |
long integer |
LClassName; |
reference |
an instance of class ClassName |
S |
short |
signed short |
Z |
boolean |
true or false |
[ |
reference |
one array dimension |
2.3.2、方法描述符
官网:https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.3.3
示例:
The method descriptor for the method:
1 | Object m(int i, double d, Thread t) {...} |
is:
1 | (IDLjava/lang/Thread;)Ljava/lang/Object; |
2.4、解读方法字节码
1 | public static void main(java.lang.String[]); |
2.4.1、图解
2.5、研究 i++ 与 ++i 的不同
我们都知道,i++表示,先返回再+1,++i表示,先+1再返回。它的底层是怎么样的呢? 我们一起探究下。
编写测试代码:
1 | public class Test2 { |
2.5.1、查看class字节码
1 | Classfile /F:/code/bestqiang-jvm/bestqiang-jvm-test/target/classes/cn/bestqiang/jvm/Test2.class |
2.5.2、对比
i++:
1 | 0: iconst_1 //将数字1压入到操作栈 |
++i:
1 | 0: iconst_1 //将数字1压入到操作栈 |
区别:
- i++
- 只是在本地变量中对数字做了相加,并没有将数据压入到操作栈
- 将前面拿到的数字1,再次从操作栈中拿到,压入到本地变量中
- ++i
- 将本地变量中的数字做了相加,并且将数据压入到操作栈
- 将操作栈中的数据,再次压入到本地变量中
小结:可以通过查看字节码的方式对代码的底层做研究,探究其原理。
2.6、字符串拼接
字符串的拼接在开发过程中使用是非常频繁的,常用的方式有三种:
- +号拼接: str+”456”
- StringBuilder拼接
- StringBuffer拼接
StringBuffer是保证线程安全的,效率是比较低的,我们更多的是使用场景是不会涉及到线程安全的问题的,所以更多的时候会选择StringBuilder,效率会高一些。
那么,问题来了,StringBuilder和“+”号拼接,哪个效率高呢?接下来我们通过字节码的方式进行探究。
首先,编写个示例:
1 | package cn.bestqiang.jvm; |
查看Test3.class的字节码
1 | Classfile /F:/code/bestqiang-jvm/bestqiang-jvm-test/target/classes/cn/bestqiang/jvm/Test3.class |
从解字节码中可以看出,m1()方法源码中是使用+号拼接,但是在字节码中也被编译成了StringBuilder方式。
所以,可以得出结论,字符串拼接,+号和StringBuilder是相等的,效率一样。
接下来,我们再看一个案例:
1 | package cn.bestqiang.jvm; |
m1() 与 m2() 哪个方法的效率高?
依然是通过字节码的方式进行探究。
1 | Classfile /F:/code/bestqiang-jvm/bestqiang-jvm-test/target/classes/cn/bestqiang/jvm/Test4.class |
可以看到,m1()方法中的循环体内,每一次循环都会创建StringBuilder对象,效率低于m2()方法。
2.7、小结
使用字节码的方式可以很好查看代码底层的执行,从而可以看出哪些实现效率高,哪些实现效率低。可以更好的对我们的代码做优化。让程序执行效率更高。
3、代码优化
优化,不仅仅是在运行环境进行优化,还需要在代码本身做优化,如果代码本身存在性能问题,那么在其他方面再怎么优化也不可能达到效果最优的。
3.1、尽可能使用局部变量
调用方法时传递的参数以及在调用中创建的临时变量都保存在栈中速度较快,其他变量,如静态变量、实例变量等,都在堆中创建,速度较慢。另外,栈中创建的变量,随着方法的运行结束,这些内容就没了,不需要额外的垃圾回收。
3.2、尽量减少对变量的重复计算
明确一个概念,对方法的调用,即使方法中只有一句语句,也是有消耗的。所以例如下面的操作:
1 | for (int i = 0; i < list.size(); i++) |
建议替换为:
1 | int length = list.size(); |
这样,在list.size()很大的时候,就减少了很多的消耗。
3.3、尽量采用懒加载的策略,即在需要的时候才创建
1 | String str = "aaa"; |
3.4、异常不应该用来控制程序流程
异常对性能不利。抛出异常首先要创建一个新的对象,Throwable接口的构造函数调用名为fillInStackTrace()的本地同步方 法,fillInStackTrace()方法检查堆栈,收集调用跟踪信息。只要有异常被抛出,Java虚拟机就必须调整调用堆栈,因为在处理过程中创建 了一个新的对象。异常只能用于错误处理,不应该用来控制程序流程。
3.5、不要将数组声明为public static final
因为这毫无意义,这样只是定义了引用为static final,数组的内容还是可以随意改变的,将数组声明为public更是一个安全漏洞,这意味着这个数组可以被外部类所改变。
3.6、不要创建一些不使用的对象,不要导入一些不使用的类
这毫无意义,如果代码中出现”The value of the local variable i is not used”、”The import java.util is never used”,那么请删除这些无用的内容
3.7、程序运行过程中避免使用反射
反射是Java提供给用户一个很强大的功能,功能强大往往意味着效率不高。不建议在程序运行过程中使用尤其是频繁使用反射机制,特别是 Method的invoke方法。
如果确实有必要,一种建议性的做法是将那些需要通过反射加载的类在项目启动的时候通过反射实例化出一个对象并放入内存。
3.8、使用数据库连接池和线程池
这两个池都是用于重用对象的,前者可以避免频繁地打开和关闭连接,后者可以避免频繁地创建和销毁线程。
3.9、容器初始化时尽可能指定长度
容器初始化时尽可能指定长度,如:new ArrayList<>(10); new HashMap<>(32); 避免容器长度不足时,扩容带来的性能损耗。
3.10、ArrayList随机遍历快,LinkedList添加删除快
3.11、使用Entry遍历Map
1 | Map<String,String> map = new HashMap<>(); |
避免使用这种方式:
1 | Map<String,String> map = new HashMap<>(); |
3.12、不要手动调用System.gc();
3.13、String尽量少用正则表达式
正则表达式虽然功能强大,但是其效率较低,除非是有需要,否则尽可能少用。
replace() 不支持正则
replaceAll() 支持正则
如果仅仅是字符的替换建议使用replace()。
3.14、日志的输出要注意级别
1 | // 当前的日志级别是error |
3.15、对资源的close()建议分开操作
1 | try{ |