springboot、jvm调优（设置运行的参数）

1、工具

jdk自带的工具位置：



找到窗口->应用程序

2、问题和方式

在SpringBoot项目中，调优主要通过配置文件和配置JVM的参数的方式进行。

2.1 springboot修改配置文件调优

关于修改配置文件application.properties。

https://docs.spring.io/spring-boot/docs/current/reference/html/common-application-properties.html#common-application-properties

其中比较重要的配置

server.tomcat.max-connections=0 #服务器在任何给定时间接受和处理的最大连接数
time.server.tomcat.max-http-header-size=0 # HTTP消息的最大大小（以字节为单位）
header.server.tomcat.max-http-post-size=0 # HTTP头部的最大大小（以字节为单位）
content.server.tomcat.max-threads=0 # 最大工作数
threads.server.tomcat.min-spare-threads=0 #最小工作线程数

2.2jvm调优

jvm官放调优文档

https://docs.oracle.com/middleware/11119/wls/PERFM/jvm_tuning.htm#i1146060

实战：

1、未设置JVM参数的情况

有一个项目，默认情况下，没有设置任何Jvm参数。下面我来启动看一下



看一下堆栈分配：很明显默认的最大堆 内存分配了8个G。很明显的不合理



2、下面我们来设置下Jvm参数，例如要配置JVM这么一大段参数：

 -XX:MetaspaceSize=128m  -XX:MaxMetaspaceSize=128m  -Xms1024m -Xmx1024m -Xmn256m  -Xss256k -XX:SurvivorRatio=8 -XX:+UseConcMarkSweepGC

方式一：

如果你用的是IDEA等开发工具，来启动运行项目，那么要调试JDK就方便太多了。只需要将参数值设置到VM options中即可。



设置成功，我的GC日志和堆栈分配都已经OK了。GC日志：



堆栈分配：



方式二：

适用于在项目部署后，在启动的时候，采用脚本或者命令行运行的时候设置。

先在项目路径下，给项目打包：

mvn clean
mvn package -Dmaven.test.skip=true

执行启动设置Jvm参数的操作

java -jar -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=128m -Xms1024m -Xmx1024m -Xmn256m -Xss256k -XX:SurvivorRatio=8 -XX:+UseConcMarkSweepGC newframe-1.0.0.jar

堆栈都是按照启动时候，设置的Jvm参数启动的。

3、参数说明

点击查看代码

-XX:MetaspaceSize=128m (元空间默认大小)
-XX:MaxMetaspaceSize=128m (元空间最大大小)
-Xms1024m(设置堆的初始值，一般设置成和Xmx一样来避免动态扩容)
-Xmx1024m（堆的最大值，一般未操作系统的2/3大小）
-Xmn256m(新生代大小，默认新生代占堆大小的1/3。高并发快消亡场景可适当加大这个区域。对半，或者更多，都是可以的。但是在G1下，就不用再设置这个值了，它会自动调整)
-Xss256k (-Xss 设置栈的大小，默认为1M，已经足够用了)
-XX:SurvivorRatio=8(新生代分区比例8：2 表示伊甸区和幸存区的比例)
-XX:+UseConcMarkSweepGC(要指定JVM使用的垃圾回收器。尽量不要靠默认值去保证，要显式的指定一个。)
-XX:+PrintGCDetails(打印详细的GC日志)

注意：

JDK8之后把-XX:PermSize 和 -XX:MaxPermGen移除了，取而代之的是

-XX:MetaspaceSize=128m (元空间默认大小)

-XX:MaxMetaspaceSize=128m (元空间最大大小)

JDK 8开始把类的元数据放到本地化的堆内存(native heap)中，这一块区域就叫Metaspace，中文名叫元空间。

使用本地化的内存有什么好处呢？最直接的表现就是java.lang.OutOfMemoryError: PermGen 空间问题将不复存在，因为默认的类的元数据分配只受本地内存大小的限制，也就是说本地内存剩余多少，理论上Metaspace就可以有多大(貌似容量还与操作系统的虚拟内存有关？这里不太清楚)，这解决了空间不足的问题。

不过，让Metaspace变得无限大显然是不现实的，因此我们也要限制Metaspace的大小：使用-XX:MaxMetaspaceSize参数来指定Metaspace区域的大小。JVM默认在运行时根据需要动态地设置MaxMetaspaceSize的大小。

垃圾回收机制原理：

https://blog.csdn.net/qq_41946216/article/details/131201057

Java 提供了多种不同的垃圾收集器，每个垃圾收集器都有其独特的优势和适用场景。以下是几种常见的垃圾收集器及其主要特点的比较：

Serial 垃圾收集器：
单线程收集器，适用于小型或简单的应用程序。
使用复制算法进行新生代垃圾收集，产生较短的停顿时间。
适合于客户端应用或调试环境。

Parallel 垃圾收集器：
多线程收集器，在新生代和老年代均可使用。
采用复制算法进行新生代垃圾收集，标记-清除-整理算法进行老年代垃圾收集。
可以通过增加线程数量来提高吞吐量。
适合于数据处理或批量作业等需要高吞吐量的场景。

CMS (Concurrent Mark-Sweep) 垃圾收集器：
并发收集器，在老年代进行垃圾收集时，尽可能减少停顿时间。
使用标记-清除算法进行垃圾收集，但不会进行内存整理。
具有较低的停顿时间，适合对响应时间有要求的应用程序。
适合于中型至大型的 Web 应用。

G1 (Garbage-First) 垃圾收集器：
并发收集器，面向大堆内存，能够处理复杂的内存布局。
将堆内存划分为多个区域，采用复制算法进行收集。
可以并发地进行垃圾收集，减少停顿时间。
高度可预测的暂停时间，适合于需要低停顿时间的应用程序。
以上只是一些常见的垃圾收集器，Java 还提供了其他垃圾收集器如 ZGC 和 Shenandoah，它们针对特定的场景和需求提供了更高级别的性能和吞吐量优化。

选择适当的垃圾收集器取决于应用程序的特点、硬件环境和性能需求。在进行选择时，建议进行实际测试和基准测试，以确定最适合的垃圾收集器。