Spring Boot 2.x性能异常排查：升级至2.1后负载测试耗时激增

Hey Steve, sorry to hear this Spring Boot upgrade is throwing such a frustrating performance curveball—especially since you’ve already ruled out Tomcat and Hibernate as culprits. Let’s dive into targeted troubleshooting angles focused on the remaining variables: Spring Boot itself, its default configurations, and how it interacts with your JDBC stack.

Key Troubleshooting Directions #

1. Audit HikariCP Configuration Differences #

Even though both versions use HikariCP, Spring Boot 2.x overhauled many default settings for the connection pool compared to 1.5. These changes could silently impact database IO efficiency:

• Compare default parameters: Check values like maximumPoolSize, minimumIdle, connectionTimeout, and idleTimeout. Spring Boot 2.1 might have lower default pool sizes or stricter timeouts that lead to more connection waits, which get attributed to FilterInputStream.read calls.
• Check for enabled metrics/monitoring: Spring Boot 2.x enables more Hikari metrics by default (via Micrometer integration). Extra metric collection can add overhead to connection operations, indirectly slowing down IO reads.
• Verify connection test queries: Spring Boot 2 might auto-configure a connection-test-query for MariaDB that wasn’t present in 1.5. Frequent test queries can add latency to connection reuse, which shows up in IO-related methods.

To compare configurations, print out the full Hikari properties in both environments using @ConfigurationProperties(prefix = "spring.datasource.hikari") and log them at startup.

2. Dig Into Spring JDBC/Transaction Behavior Changes #

Spring 5.x (shipped with Boot 2.1) introduced subtle changes to JDBC handling that could affect ResultSet and IO operations:

• Fetch size defaults: Check if JdbcTemplate or Hibernate’s JDBC interaction uses a different default fetchSize. A smaller fetch size forces more round-trips to the database, making each read call appear slower (or accumulate more total time).
• Transaction synchronization: Spring 5 updated transaction synchronization logic. If your app uses transactional methods heavily, this could change how connections are acquired/released, leading to more context switching during IO operations.
• ResultSet handling: Spring might now use different ResultSet types (e.g., scrollable vs. forward-only) or fetch modes by default. These changes can alter how data is streamed from the database, increasing read latency.

3. Compare JVM Runtime Differences #

Spring Boot 2.x has different default JVM settings and compatibility requirements that could impact IO performance:

• GC configuration: Spring Boot 2.1 defaults to G1GC (for JDK 8+), while 1.5 used ParallelGC. G1GC has different pause behavior that might make IO operations appear slower if GC pauses overlap with database reads. Use tools like jstat or jvisualvm to compare GC pause times between the two versions.
• Class loading and bytecode enhancement: Spring Boot 2 uses a different classloader structure (e.g., LaunchedURLClassLoader) and more aggressive bytecode enhancement. This could affect how the MariaDB driver’s FilterInputStream is loaded or optimized by the JVM, leading to slower execution.
• JVM flags: Check if Spring Boot 2 adds default flags like -XX:+UseStringDeduplication or others that introduce overhead during IO operations. Compare the full JVM argument list for both environments.

4. Investigate MariaDB Driver and Spring Boot Compatibility #

Even though your driver version is unchanged, Spring Boot 2’s classpath and auto-configurations might alter how the driver interacts with the database:

• Connection property defaults: Spring Boot 2 might auto-add JDBC URL parameters (e.g., useSSL=true, serverTimezone=UTC) that weren’t present in 1.5. Some of these parameters can enable extra validation or encryption that slows down IO reads.
• Driver class loading: The MariaDB driver’s classes might be loaded by a different classloader in Spring Boot 2, preventing JVM optimizations (like JIT compilation) that were active in 1.5. Use jinfo to check the classloader hierarchy for MariaDB IO-related classes.
• Connection lifecycle management: Spring Boot 2’s DataSourceAutoConfiguration might tweak how connections are pooled or validated, leading to more frequent connection creation/destruction. New connections have higher overhead, which can bleed into read operation timings.

5. Deepen Performance Profiling #

You’ve already identified FilterInputStream.read as the bottleneck—go a level deeper to pinpoint why it’s slower:

• Drill into the call stack: Use your profiler to see exactly what’s triggering the read calls (e.g., ResultSet.next(), blob streaming, etc.). Compare the call stacks between Spring Boot 1.5 and 2.1 to spot differences in how data is fetched.
• Measure actual IO vs. processing time: Use a tool like AsyncProfiler to split the read method’s time into network wait time and client-side processing time. If network wait time is higher, focus on connection pool or network settings; if processing time is higher, look at JVM or driver classloader issues.
• Capture database traffic: Use tcpdump or Wireshark to capture database packets in both environments. Compare the time between sending a query and receiving the first byte of data—this will tell you if the latency is coming from the database network or the application’s processing.

Final Notes #

Since you’ve ruled out Tomcat and Hibernate, the issue is likely tied to a subtle default configuration change in Spring Boot 2.x or how it interacts with the JDBC stack at a low level. Start with comparing Hikari and JVM settings first—those are the most common culprits in these types of upgrade performance hits.

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