如何自己做资源网站整站优化代理
JVM 核心配置与调优指南
一、堆内存与年轻代配置（影响最大）
- 堆内存大小： 在资源允许的前提下，堆内存应尽可能设置得更大。关键点： 必须将堆内存的最大值 (
-Xmx) 和最小值 (-Xms) 设置为相同值。动态扩容会触发 Full GC，影响性能。元空间 (-XX:MaxMetaspaceSize/-XX:MetaspaceSize) 同理，也应设置相同的最大最小值。 - 年轻代占比： 通常建议设置较大的年轻代比例（例如，通过
-Xmn或-XX:NewRatio）。在 ZGC 之前的回收器（如 Parallel Scavenge, CMS, G1）中，Young GC 是 STW 的，更大的年轻代可以减少 Young GC 的频率。
二、垃圾回收器选型策略
- 低延迟不敏感场景（如 OLAP、批处理）： 优先选择 Parallel Scavenge + Parallel Old 组合。这对回收器以最大化吞吐量为设计目标。
- 低延迟敏感场景（如 Web 服务、API）： 推荐使用 G1 (Garbage-First) 回收器。虽然《深入理解Java虚拟机》提到小内存下 CMS 可能更优，但作者实践测试表明，在各种大小内存场景下，G1 的表现通常优于 CMS，更符合现代应用对低延迟的需求。
三、高并发场景下的特殊考量
高并发应用对 GC 停顿极其敏感，应优先选择低停顿回收器（如 G1），而非高吞吐量回收器（如 Parallel Scavenge/Old）。原因在于：
- Parallel Scavenge/Old 的 Young GC 和 Full GC 都是完全 STW 的。
- G1 的 Mixed GC 部分阶段能与用户线程并发执行，显著减少 STW 时间。
- 恶性循环风险： 高并发下发生 STW 时，GC 线程（优先级较低）与处理用户请求的线程竞争 CPU 资源。操作系统可能优先调度用户请求线程，导致 GC 线程获得的时间片减少，进而延长 STW 时间。延长的 STW 又会导致请求堆积，进一步增加 GC 压力（频率升高、效率降低），形成性能恶化循环。减少 STW 是打破此循环的关键。
四、其他重要配置规范
- 栈大小 (
-Xss)： 默认 1MB 通常过大。建议设置为 256k 或更低（如-Xss256k），可减少StackOverflowError发生概率，并节省内存。 - 堆/元空间固定大小： 重申第一条关键点，
-Xmx=-Xms,-XX:MaxMetaspaceSize=-XX:MetaspaceSize，避免扩容触发 Full GC。 - OOM 时 Dump 日志 (
-XX:+HeapDumpOnOutOfMemoryError,-XX:HeapDumpPath)： 发生OutOfMemoryError时自动生成堆转储文件，便于事后分析。 - Full GC 前后 Dump (谨慎使用)： 通过 JVM 参数或工具（如
jcmd）触发 Full GC 前后的堆转储。警告： Dump 操作消耗大量 CPU 和 I/O 资源，强烈反对在生产环境使用，仅限测试环境诊断。 - 禁止线上远程调试：严禁在生产环境开启 JVM 的远程调试端口（如
-agentlib:jdwp），存在严重安全风险且影响性能。 - 禁止显式调用
System.gc()： 代码中禁止调用System.gc()或Runtime.getRuntime().gc()。这会强制触发 Full GC，干扰 JVM 自身的 GC 策略，通常导致不必要的性能损耗。 - 避免追求极短停顿时间： 理解 JVM GC 的“不可能三角”（低延迟、高吞吐量、小内存占用）。试图通过参数（如 G1 的
-XX:MaxGCPauseMillis）将目标停顿时间设置得过短，往往会导致 GC 频率显著增加，反而降低整体吞吐量。设置合理的目标值更为重要。