Java 9与Tomcat 7.0.73启动报错咨询：GC线程配置及错误影响与解决

嘿，我之前在Java 9搭配老版本Tomcat的时候也踩过这个坑，给你详细梳理下这个问题的来龙去脉和解决办法：

一、这个错误的实际影响 #

先给你吃个定心丸：既然应用能正常启动，这个错误的直接影响非常小。这个JreMemoryLeakPreventionListener是Tomcat用来提前预防内存泄漏的辅助组件，它只是尝试创建GC守护线程失败了，但核心的应用服务逻辑完全不受影响。

不过要留意潜在风险：

• 这个Listener原本的作用是提前加载一些JRE核心类、触发GC相关逻辑，避免后续应用类加载器意外持有这些类的引用导致内存泄漏。失败后，在长时间运行或者频繁热部署、重启应用的场景下，可能会增加内存泄漏的概率，但不是必然会发生。
• 它不会导致应用崩溃，只是Tomcat的“内存泄漏预防针”没打成功而已。

二、错误原因&可行的规避方案 #

这个问题本质是Java 9的模块系统（JPMS）和Tomcat 7.0.73的兼容性问题。Tomcat 7.0.73发布时Java 9还没正式推出，Listener里用的一些反射调用在Java 9的模块权限控制下失效了，没法成功创建GC守护线程。

给你几个解决思路：

• 优先升级Tomcat版本：Tomcat 8.5.x及以上的版本已经完全适配了Java 9，这个问题会被彻底修复。如果业务允许升级，这是最省心的方案。
• 临时禁用该Listener：如果暂时没法升级Tomcat，可以直接在conf/server.xml里注释掉这个Listener的配置。找到类似下面的行，把它注释掉：

  <!-- <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" /> -->
  

  注意：禁用后会失去它的内存泄漏预防能力，要是你的应用有频繁热部署的场景，记得多关注内存使用情况。
• 调整Java 9的JVM参数：给Tomcat的启动参数添加模块权限开放配置。在bin/catalina.sh（Linux）或bin/catalina.bat（Windows）里，找到JVM参数配置部分，添加：

  --add-opens java.base/java.lang=ALL-UNNAMED
  

  这个参数允许Tomcat的代码通过反射访问java.base模块里的java.lang包内容，能解决创建GC守护线程的权限问题。

三、Tomcat创建GC守护线程的原因 #

Tomcat搞这个GC守护线程，核心目的就是防内存泄漏：

• 在Java里，如果某些JRE核心类被应用类加载器加载了，这些类可能会持有应用类加载器的引用，导致应用类加载器在热部署、重启时无法被GC回收，进而引发内存泄漏。
• GC守护线程是个低优先级线程，它会提前持有系统类加载器的引用，让JVM用系统类加载器初始化这些关键的GC相关类，避免应用类加载器去加载它们，从根源上减少类加载器泄漏的可能性。
• 简单说就是提前“占坑”，让系统类加载器负责这些核心类，不让应用类加载器碰，防止后续类加载器“赖着不走”。

四、GC守护线程的配置选项 #

Tomcat的JreMemoryLeakPreventionListener提供了参数可以控制GC守护线程的创建：

• 你可以在server.xml的Listener配置里添加gcDaemonEnabled参数，比如：

  <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" gcDaemonEnabled="false" />
  

  把它设为false就会关闭GC守护线程的创建，这样也能避免这个错误，但同样会失去对应的内存泄漏预防能力。
• 不过在Java 9环境下，即使开启这个参数，还是会因为权限问题报错，所以更推荐前面的升级或JVM参数调整方案。

内容的提问来源于stack exchange，提问作者learner