如何降低内嵌Tomcat的Spring Boot应用内存占用？相关疑问解答

Hey there, let's walk through each of your questions with practical, actionable advice based on your scenario of running 7 Spring Boot JARs on a single server:

1. Are there more memory optimization approaches available? #

Absolutely—here are some targeted tweaks beyond just adjusting JAVA_OPTS:

• Trim down dependencies:
  • Remove devtools and test dependencies from production builds entirely (they're only for development). Use Maven/Gradle profiles to exclude them in prod.
  • Replace spring-boot-starter-web with spring-boot-starter-webflux if your services can use non-blocking I/O—this eliminates the heavy embedded Tomcat footprint and uses Netty instead.
  • Exclude unused auto-configurations with @SpringBootApplication(exclude = {DataSourceAutoConfiguration.class, RabbitAutoConfiguration.class}) if a service doesn't need DB or RabbitMQ.
• Fine-tune JVM parameters:
  • Set Xms equal to Xmx (e.g., -Xmx200m -Xms200m) to avoid JVM resizing the heap, which causes memory fluctuations.
  • Limit metaspace (where class metadata lives) with -XX:MaxMetaspaceSize=128m -XX:CompressedClassSpaceSize=64m—this prevents it from eating up unallocated memory.
  • Use modern GC algorithms like G1GC (-XX:+UseG1GC) or ZGC (for JDK 11+) to minimize pause times and stabilize memory usage.
• Optimize Spring Boot runtime:
  • Enable lazy initialization with spring.main.lazy-initialization=true to only load beans when they're first needed, reducing startup and idle memory.
  • Disable unused Actuator endpoints (e.g., set management.endpoints.web.exposure.include=health,info instead of exposing all).
  • Tune embedded container settings: For Tomcat, lower thread pool limits with server.tomcat.max-threads=10 and server.tomcat.min-spare-threads=2 to cut down on idle thread memory.

2. How to troubleshoot components/dependencies that use high memory? #

You can use a mix of JVM tools and Spring-specific utilities to pinpoint culprits:

• Heap dump analysis:
  • Generate a heap dump with jmap -dump:format=b,file=heap.hprof <your-service-pid>, then open it with VisualVM (built into JDK) or JProfiler. Look for large object instances (e.g., cached JPA entities, RabbitMQ connection pools) or unexpected class loads.
  • Use Spring Boot Actuator's /actuator/heapdump endpoint to download a dump directly from the running service (make sure this endpoint is secured in production).
• Dependency auditing:
  • Run mvn dependency:tree (or ./gradlew dependencies for Gradle) to spot redundant or heavy dependencies. For example, some starters pull in unused transitive dependencies you can exclude.
• Real-time monitoring:
  • Use jstat -gc <pid> to track GC activity over time—frequent full GCs might indicate memory leaks or misconfigured heap sizes.
  • Try Arthas (a Java diagnostic tool) to run heapdump or trace commands to see which methods are creating excessive objects.

3. Is memory fluctuation caused by the embedded Tomcat? #

This is a very likely culprit—here's why and how to verify:

• Embedded Tomcat maintains a thread pool, and even idle threads take up memory for their stacks and context. When requests come in (even health checks), Tomcat may spin up threads, and when idle, it keeps some alive per min-spare-threads settings, causing memory to rise and fall as threads are created/destroyed or GC'd.
• Tomcat also uses internal buffers (for request/response processing) and class loaders that can contribute to memory swings.
• How to test:
  • Swap Tomcat for a lighter container like Undertow: Replace spring-boot-starter-web with spring-boot-starter-undertow and observe if fluctuations calm down.
  • Tune Tomcat's thread pool aggressively: Set server.tomcat.max-threads=5 and server.tomcat.min-spare-threads=1 to reduce idle thread overhead.
  • Note: Normal JVM GC activity will also cause minor memory fluctuations—if the swings are small (tens of MB), that's expected. Only worry if it's jumping hundreds of MB or causing OOM errors.

4. Will exporting to WAR and deploying to JBoss/Tomcat reduce memory usage? #

Yes, but it depends on your setup—here's the breakdown:

• Memory savings come from shared resources:
  • Multiple WARs on a single app server share the same JVM and container class loader. This means common libraries (like Spring Core, Eureka Client) are loaded once instead of 7 times (once per JAR), cutting down significantly on metaspace and heap memory from duplicate class loads.
  • Shared thread pools (managed by the app server) are more efficient than each JAR running its own embedded Tomcat thread pool—you avoid redundant idle threads across services.
• Caveats to consider:
  • Dependency version conflicts: If your services use different versions of the same library, you might hit class loading issues (e.g., NoClassDefFoundError or LinkageError).
  • Single point of failure: A crash in the app server affects all your services, whereas JARs run as separate processes and isolate failures.
  • Less granular control: You can't set unique JVM parameters per service—all WARs share the same JAVA_OPTS for the app server.

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