Apache性能调优需围绕JVM、连接模型、线程调度、GC与业务特征闭环验证：堆设4g/32GB上限，G1 GC调优，Metaspace预留256m~512m；maxThreads按QPS×响应时间估算，keepAlive复用连接；禁用同步远程调用，异步需独立线程池；必须嵌入Micrometer/Prometheus监控与JFR深度分析，建立“监控→压测→调参→验证→固化”循环。
Apache性能调优在Java生产环境不是“配完就完”，而是需要围绕JVM、连接模型、线程调度、GC行为与业务特征做闭环验证。核心原则是：不盲目调参，先观测瓶颈，再定向干预，每次只改一项并对比效果。
一、JVM层必须对齐Apache工作负载
Apache（如Tomcat）本质是JVM进程，其堆内存、GC策略、元空间配置直接影响请求吞吐与响应延迟：
- 堆大小建议设为物理内存的50%~70%，但不超过32GB（避免指针压缩失效），例如16核64GB机器可设 -Xms4g -Xmx4g；
- 优先使用G1 GC（JDK9+默认），启用 -XX:+UseG1GC -XX:MaxGCPauseMillis=200，避免Full GC频繁触发；
- 元空间（Metaspace）需预留足够空间，尤其使用大量动态类（如Spring Boot + AOP），建议设 -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m；
- 禁用显式GC（-XX:+DisableExplicitGC），防止框架中误调用
System.gc()扰乱GC节奏。
二、连接器（Connector）按真实流量建模调优
以Tomcat的NIO/NIO2或APR Connector为例，参数必须匹配并发模型与网络质量：
- maxThreads 不等于CPU核数×2，而应基于平均响应时间与QPS估算：若P95响应耗时300ms，目标QPS=1000，则最小线程数 ≈ 1000 × 0.3 = 300，建议设为300~400；
- acceptCount 是等待队列长度，非连接总数，生产建议设为100~200（避免SYN队列溢出或线程饥饿）；
- 启用 keepAliveTimeout（如60秒）和 maxKeepAliveRequests（如100），复用连接降低TLS握手开销；
- NIO模式下，selectorTimeout 建议设为1000（毫秒），避免Selector空轮询消耗CPU。
三、线程池与异步行为需端到端收敛
Apache自身线程池只是入口，后端调用（DB、RPC、缓存）若未适配，会形成线程阻塞放大效应：
立即学习“Java免费学习笔记（深入）”；
- 禁止在Servlet线程中执行同步远程调用或长IO操作，必须转为异步（如CompletableFuture + 自定义线程池）；
- 自定义业务线程池需独立于Tomcat线程池，拒绝策略推荐 CallerRunsPolicy，避免请求丢失；
- 若使用Spring WebMvc，确认 @Async 的线程池已配置核心/最大线程数与队列容量，避免默认SimpleAsyncTaskExecutor导致线程爆炸；
- 监控 ThreadPoolExecutor.getActiveCount() 和 getQueue().size()，及时发现堆积风险。
四、可观测性必须前置嵌入，而非事后补救
调优有效性依赖真实指标反馈，不能仅靠日志或单点监控：
- 暴露JVM指标（GC次数/耗时、堆内存各区使用率、线程数）通过Micrometer + Prometheus采集；
- 记录Connector级指标：当前活动连接数（currentThreadsBusy）、处理请求数（requestCount）、错误数（errorCount）；
- 对关键接口打点，统计从Acceptor接收→Processor解析→Filter链→Servlet执行的各阶段耗时（可用Spring Boot Actuator + TimedAspect）；
- 开启JDK Flight Recorder（-XX:+FlightRecorder -XX:StartFlightRecording=duration=60s,filename=/tmp/recording.jfr），用于深度分析GC停顿、锁竞争、方法热点。
落地关键不是参数本身，而是建立“监控→压测→调参→验证→固化”的循环机制。每次上线前用JMeter或Gatling模拟真实流量路径，重点关注P99延迟拐点与错误率突增位置。不复杂但容易忽略。
