Tomcat 性能调优之 JVM 调优

关注

转载最新推荐文章于 2026-03-26 09:18:20 发布 418 阅读 AI 写同款· GEO 优化 ›

Tomcat与JVM性能调优（详细） Tomcat性能调优找到Tomcat根目录下的conf目录，修改server.xml文件的内容。对于这部分的调优，我所了解到的就是无非设置一下Tomcat服务器的最大并发数和Tomcat初始化时创建的线程数的设置，当然还有其他一些性能调优的设置，下图是我根据我机子的性能设置的一些参数值，给各位详细解释一下吧： 1、URIEncoding=“UTF-8”：设置Tomcat的字符集。这种配置我们一般是不会设置的，因为关于乱码的转换我们会在具体项目中具体处理，直接修改Tomcat的字符集未免过于太死板。 2、阅读详情

之前一直对于JVM调优这块比较混淆，看到这篇文章后豁然开朗，好文应该分享，记录下来，慢慢“品味”。

文章转自来源

Tomcat、Jetty、GlassFish 等等这系列 Web容器/应用服务器，虽然做为容器，提供的是一个 Java Web 的运行时环境，以支持Servlet/JSP 等等这些内容的运行，但我们都很清楚，其本质上还是一个 Java 应用程序。每次对于容器的启动运行，都是把这个 Java 程序跑起来，来实现 Web 容器的能力。

做为一类“特殊”的 Java 应用程序，和任务其他的 Java 应用一样，需要使用到JVM，会有堆，会使用到垃圾回收，会涉及到不同的堆分区比例...

因此在对Web 容器( 应用服务器) 的调优中必不可少的是对于 JVM 的调优。

对于 JVM 的调优，主要有两个方面考虑：

内存大小配置
垃圾回收算法选择

当然，确切的说，以上两点并不互相独立，内存的大小配置也会影响垃圾回收的执行效率。

其中内存大小配置，最主要做的有

确定内存占用的总大小
确定内存中各个代(Gen) 的大小划分

内存大小配置

所谓内存大小的占用，是指应用程序启动后稳定运行一小段时间时，观察到的内存占用情况。

以 HotSpot 虚拟机为例，Java 堆主要有三个空间：

新生代、老年代和永久代。

根据不同应用的特别，观察应用对于内存的占用，如果有大量的临时对象，不会重复使用，则可以调整 New Gen，这样这些临时对象就在新生代创建完成，并在 Minor GC 产生时被回收，这样较短生存活的对象不会晋升到老年代，从而可以避免垃圾堆集产生 Full GC。

理想状态下，短期存活的对象都只在新生代完成生命周期，被费时劲少的

Minor GC 回收完成，而长期存活，将会多次使用的在多次回收之后晋升到老年代，最终经过 Full GC 完成生命周期。

这里涉及到关于内存大小的调整参数有：

-Xms
-Xmx

这两个参数用于配置 heap 的起始大小和最大值。这里需要经过观察，找一个合适的值，设置太大会导致内存浪费，同时也会导致垃圾回收耗时太长。对于 Tomcat 来说，一般都会将初始值和最大值设置为相同值，这样就避免在初始内存不足时触发 Full GC 来进行扩展内存。

设定 heap 大小之后，要根据对象生命周期的特征，来调整新生代与老年代的大小比例。

涉及到的参数有：

-XX:NewSize
-XX:NewRatio
-XX:MaxNewSize
-Xmn

第一个是直接设置新生代初始大小，第二个是设置比例(Ratio)。太高或太低都会导致 GC 不能高效的工作。毕竟 Minor GC 也是要耗时的。最后一个设置新生代的初始值和最大值相同，堆空间的变化不影响其值。

对于使用了大量第三方类库的应用来说，会加载许多框架依赖的类，使用过程中可能会遇到因为Perm Gen 不足产生的 OOM，这种情况可以通过观察稳定状态下 Perm 区的占用，再通过参数设置。

-XX:PermSize
-XX:MaxPermSize
-XX:MaxMetaspaceSize

第一个会设置Perm区的初始大小，第二个用于设置Perm 区的最大值。在Java 8的时候， Perm 区被移除，改为Metaspace，不过如果遇到类似的OOM,依然可以调整其大小。

此外，对于使用大量线程的应用，也可以配置 -Xss，主要用于设置单个线程的stack 大小。注意，是单个的大小，因此设置值越大，会占用越大，可用的线程数也就越少。

这里的配置一般对于-X开始的可以直接在后面用数字加单位，而-XX的则需要等号后数字再加单位，例如：

java -Xms100m -Xmx200m -XX:PermSize=300m

这里数字后的单可以是m,g,k代表计算机中的不同单位。

那我们前面一直在说根据不同的应用，观察分析设置堆的大小，堆的各个代的大小，那具体观察什么呢？

我们一般在JVM的配置中增加一些打印 GC 日志的选项，配置方式和上面的类似，这样在 GC 产生时，会打印出各个代占用的大小，具体触发时间等。推荐的配置有以下几个：

-XX:+PrintGCTimeStamps
-XX:+PrintGCDetails
-Xloggc:<文件名>
-XX:PrintGCDateStamps

第一个和第四个选项可以任选一个，第一个打印自JVM启动以来的时间，一般也称为uptime, 第四个打印的是系统当前日期和时间。

根据 GC 日志产生的内容，来观察具体的大小，开始使用上述的配置参数进行调整。当然，也可以用 JConsole, JVisual VM 这些工具可视化的进行了解再调整。

垃圾回收算法

不同的垃圾回收算法，对于应用的影响很大。一方面可能在一个服务器上却使用了单线程的回收算法，也可能应用对于响应要求很高，但却使用了一个吞吐量优先的算法，导致响应太慢。

所以对于垃圾回收算法的选择，一般都是根据应用的特点，是要低延迟还是高吞吐量，选择合适的算法。我们前面也提到，垃圾回收算法和内存的大小配置并非独立的，内存设置大是回收的频率会降低，但每次的执行时间也会变长。所以这里也是一个需要权衡的地方。

延迟、吞吐量调优
其他 JVM 配置

垃圾回收算法对应到的就是不同的垃圾收集器，具体到在 JVM 中的配置，是使用 -XX:+UseParallelOldGC 或者 -XX:+UseConcMarkSweepGC 这种不同的收集器来达到选择算法的目的。

其中 ParallelGC 也称为吞吐量优先收集器，可以提升应用的吞吐量，但在老年代大小调整之，进行几次垃圾回收后，不能满足应用的低延迟要求。

一般常用到ConcMarkSweepGC，也称之为 CMS GC，其可以做到老年代的垃圾回收与应用程序的纯种并行执行，所以可以实现低延迟。

这里注意，由于 CMS GC 和其他GC回收算法使用的框架不同，因此不能混用，在使用CMS 进行老年代回收时，新生代默认使用了单线程回收算法，此时可以通过配置 -XX:+UseParNewGC来使用新生代并行回收。

由于CMS是垃圾回收和应用线程并行，因此需要额外的CPU处理资源，如果只有一个CPU的机器，或者有多个忙碌的CPU，又想要使用低延迟的收集器，此时可以通过配置 CMS 收集器的增量模式来进行回收，通过指定 -XX:+CMSIncrementalMode 来开启增量模式。此时交替运行垃圾收集器应用线程。通过配置

-XX:CMSIncrementalSafetyFactor=X， -XX:CMSIncrementalDutyCycleMin=Y,

-XX:CMSIncrementalPacing 可以控制垃圾收集后台线程为应用线程让出多少CPU周期。

参数-XX:+CMSParallelRemarkEnabled 用来降低标记停顿，另外由于CMS 回收后的老年代内存空间并不是连续的，因此通过参数

-XX:+UseCMSCompactAtFullCollection 在Full GC的时候对年老代的压缩。

在JDK1.7 的时候引入了 G1 收集器，可以通过配置-XX:+UseG1GC 来开启。这一方面的实战经验不多，有相关使用经验的朋友欢迎分享。

此外，还可以对新生代进行更细致的配置，比如设置Eden 和 Suvivor 区的比例等，和Newxx类似，可以通过SuvivorRation设置比例。