Tomcat及日常工作代码中JVM优化介绍

最新推荐文章于 2024-08-19 14:16:49 发布

qqxhb

最新推荐文章于 2024-08-19 14:16:49 发布

阅读量114

点赞数

分类专栏： Java 文章标签： JVM Tomcat

本文链接：https://blog.csdn.net/qq_43792385/article/details/100885772

版权

Java 专栏收录该内容

34 篇文章 1 订阅

订阅专栏

文章目录

1 Tomcat优化

1.1 禁用AJP连接

默认状态下会启用AJP服务，并且占用8009端口。AJP（Apache JServer Protocol） AJPv13协议是面向包的。WEB服务器和Servlet容器通过TCP连接来交互；为了节省SOCKET创建的昂贵代价，WEB服务器会尝试维护一个永久TCP连接到servlet容器，并且在多个请求和响应周期过程会重用连接。
在这里插入图片描述
我们一般是使用Nginx+tomcat的架构，所以用不着AJP协议，所以把AJP连接器禁用。修改conf下的server.xml文件，将AJP服务禁用掉即可。

<!-- <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" /> -->

1.2 执行器（线程池）

在tomcat中每一个用户请求都是一个线程，所以可以使用线程池提高性能。修改server.xml文件：

<!--将注释打开-->
<Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
    maxThreads="500" minSpareThreads="50" prestartminSpareThreads="true"
maxQueueSize="100"/>
<!--
参数说明：
maxThreads：最大并发数，默认设置 200，一般建议在 500 ~ 1000，根据硬件设施和业务来判断
minSpareThreads：Tomcat 初始化时创建的线程数，默认设置 25
prestartminSpareThreads： 在 Tomcat 初始化的时候就初始化 minSpareThreads 的参数值，如果不等于
true，minSpareThreads 的值就没啥效果了
maxQueueSize，最大的等待队列数，超过则拒绝请求
-->
<!--在Connector中设置executor属性指向上面的执行器-->
<Connector executor="tomcatThreadPool"  port="8080" protocol="HTTP/1.1"
       connectionTimeout="20000"
       redirectPort="8443" />

1.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：

<Connector executor="tomcatThreadPool"  port="8080"
protocol="org.apache.coyote.http11.Http11Nio2Protocol"
       connectionTimeout="20000"
       redirectPort="8443" />

1.4 调整JVM参数进行优化

#年轻代、老年代均使用并行收集器，初始堆内存64M，最大堆内存512M
JAVA_OPTS="-XX:+UseParallelGC -XX:+UseParallelOldGC -Xms64m -Xmx512m -
XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -
Xloggc:../logs/gc.log"

具体测试过程，使用Jmeter完成。

2 代码优化

优化，不仅仅是在运行环境进行优化，还需要在代码本身做优化，如果代码本身存在性能问题，那么在其他方面再怎么优化也不可能达到效果最优的。

2.1 尽可能使用局部变量

调用方法时传递的参数以及在调用中创建的临时变量都保存在栈中速度较快，其他变量，如静态变量、实例变量等，都在堆中创建，速度较慢。另外，栈中创建的变量，随着方法的运行结束，这些内容就没了，不需要额外的垃圾回收。

2.2 尽量减少对变量的重复计算

明确一个概念，对方法的调用，即使方法中只有一句语句，也是有消耗的。所以例如下面的操作：

for (int i = 0; i < list.size(); i++)
{}
//建议替换为
int length = list.size();
for (int i = 0,  i < length; i++)
{}

2.3 尽量采用懒加载的策略，即在需要的时候才创建

String str = "aaa";
if (i == 1){
list.add(str);
}
//建议替换成
if (i == 1){
String str = "aaa";
list.add(str);
}

2.4 异常不应该用来控制程序流程

异常对性能不利。抛出异常首先要创建一个新的对象，Throwable接口的构造函数调用名为fillInStackTrace()的本地同步方法，fillInStackTrace()方法检查堆栈，收集调用跟踪信息。只要有异常被抛出，Java虚拟机就必须调整调用堆栈，因为在处理过程中创建了一个新的对象。异常只能用于错误处理，不应该用来控制程序流程。

2.5 不要将数组声明为public static final

因为这毫无意义，这样只是定义了引用为static final，数组的内容还是可以随意改变的，将数组声明为public更是一个安全漏洞，这意味着这个数组可以被外部类所改变。

2.6 不要创建一些不使用的对象，不要导入一些不使用的类

这毫无意义，如果代码中出现"The value of the local variable i is not used"、“The import java.util is never used”，那么请删除这些无用的内容。

2.7 程序运行过程中避免使用反射

反射是Java提供给用户一个很强大的功能，功能强大往往意味着效率不高。不建议在程序运行过程中使用尤其是频繁使用反射机制，特别是 Method的invoke方法。如果确实有必要，一种建议性的做法是将那些需要通过反射加载的类在项目启动的时候通过反射实例化出一个对象并放入内存。

2.8 使用数据库连接池和线程池

这两个池都是用于重用对象的，前者可以避免频繁地打开和关闭连接，后者可以避免频繁地创建和销毁线程。

2.9 容器初始化时尽可能指定长度

容器初始化时尽可能指定长度，如：new ArrayList<>(10); new HashMap<>(32); 避免容器长度不足时，扩容带来的性能损耗。

2.10 ArrayList随机遍历快，LinkedList添加删除快

2.11 不要手动调用System.gc();

2.12 String尽量少用正则表达式

正则表达式虽然功能强大，但是其效率较低，除非是有需要，否则尽可能少用。replace() 不支持正则 replaceAll() 支持正则。如果仅仅是字符的替换建议使用replace()。

2.13 日志的输出要注意级别

2.14 对资源的close()建议分开操作

try{
  XXX.close();
  YYY.close();
}
catch (Exception e){
 ...
}
// 建议改为
try{
  XXX.close();
}
catch (Exception e){
 ...
}
try{
  YYY.close();
}
catch (Exception e){
 ...
}