Debian 上的 Java 性能问题，往往不是单点配置失误，而是环境、JVM、代码和系统参数叠在一起后的结果。与其一开始就盲调 GC，不如先把运行时版本、内存模型、并发方式和监控手段按层梳理清楚；这样你不仅能照着做，还能知道每一项配置对应解决的到底是什么问题。
先把 Debian 上的 Java 运行环境配正确
JDK 版本先选稳定版本
在 Debian 上，优先使用官方仓库提供的 OpenJDK 稳定版本即可，常见选择是 OpenJDK 11 或 17。安装完成后，先确认运行时和编译器都可用：
java -version
javac -version这一步的意义很直接：如果版本本身不统一，或者编译器、运行时指向不同路径，后面的参数调优很容易失去参考价值。
环境变量要和实际安装路径一致
如果要做全局配置，可以编辑 /etc/environment；如果只影响当前用户，编辑 ~/.bashrc 即可。关键是把 JAVA_HOME 和 PATH 配到正确位置，修改后重新加载配置，并检查变量是否生效：
source ~/.bashrc
echo $JAVA_HOME这里最常见的问题不是“没配置”，而是“路径写错了但能启动一部分命令”，结果导致线上实际运行的 Java 版本和预期不一致。
多版本共存时用 update-alternatives 管理
如果系统里安装了多个 Java 版本，直接手改软链接并不稳妥，建议统一使用 update-alternatives 切换默认的 Java 运行时和编译器。这样做更适合 Debian 的管理方式，也方便后续维护和回退。
JVM 参数怎么调，先抓住堆、GC 和线程三个核心点
堆内存先避免频繁动态扩缩容
堆大小通常建议把 -Xms 和 -Xmx 设成相同，减少运行时动态扩容和缩容带来的额外开销。例如：
-Xms4g -Xmx4g新生代与老年代的比例可以通过 -XX:NewRatio 调整，默认值是 3，也就是新生代约占整个堆的 1/4。Eden 和 Survivor 的比例则由 -XX:SurvivorRatio 控制，默认值是 8，意味着 Eden 区约占新生代的 8/10。
这些参数不一定越激进越好，但至少要知道：如果 GC 频率高，首先该怀疑的是堆空间和代际分配，而不是盲目更换收集器。
GC 收集器按场景选，不要继续把 CMS 当默认方案
垃圾回收器的选择要结合业务类型来看：
G1GC：适合大堆内存场景，尤其是超过 4GB 时，吞吐量和停顿时间比较均衡。Parallel GC：更适合高吞吐场景，例如批处理任务。CMS：虽然仍可能出现在老项目里，但已经停止维护，不建议新项目继续采用。
如果使用 G1GC，可以配合以下参数限制目标停顿时间：
-XX:MaxGCPauseMillis=200对于 GC 线程数量，文中的经验值是：并行 GC 线程数设为 CPU 核心数的一半，并发 GC 线程数设为 CPU 核心数的四分之一。这不是固定公式，但很适合作为起步参考。
GC 日志一定要开，判断依据主要看三项
只调参数不看日志，基本等于碰运气。可以通过 -Xloggc 指定日志路径，再配合这两个参数输出更完整的信息：
-Xloggc
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps后续分析时，重点看三类指标：
- GC 频率：过高通常意味着堆内存不足。
- 单次 GC 耗时：过长通常说明 GC 策略需要调整。
- 老年代 GC 占比：占比高通常说明对象存活时间偏长，内存分配方式可能需要优化。
这三项指标足够支撑大多数初步判断，比一上来堆一长串 JVM 参数更有效。
线程栈和 GC 线程数也会影响整体表现
-Xss 用来控制线程栈大小，默认通常是 1MB。在线程数较多的应用里，可以适当下调，以节省内存占用；但调得过低，可能触发 StackOverflowError。因此它属于“能改，但必须结合线程模型和调用深度验证”的参数。
代码层优化，重点是减少对象创建和选对数据结构
先减少不必要的对象分配
Java 应用很多性能问题，最终都会反映到对象分配速率和 GC 压力上。几个直接有效的做法包括：
- 避免在循环里频繁
new对象。 - 能用基本类型时，尽量不要改用包装类。
- 字符串拼接优先使用
StringBuilder，而不是反复用+。
这些调整看起来基础，但往往正是年轻代回收频繁的来源。
数据结构和算法选择，决定了上限
如果操作模式不匹配，再好的 JVM 参数也救不了代码层面的低效。文中给出的经验是：
- 频繁查找使用
HashMap，时间复杂度为 O(1)。 - 频繁插入删除使用
LinkedList，时间复杂度也是 O(1)。 - 能避免嵌套循环就尽量避免，必要时考虑排序后再用双指针等方式降低复杂度。
这一层的优化，本质上是在减少无意义的 CPU 消耗和对象中间态。
并发代码优先用现成工具，而不是手搓线程
并发场景下，建议优先使用 java.util.concurrent 提供的工具类，例如 ExecutorService 和 ConcurrentHashMap。相比手动创建线程，这类工具更容易控制线程生命周期和资源消耗。
同步策略上，也要尽量缩小锁范围。能使用 synchronized 代码块，就不要直接把整个方法都变成 synchronized。如果业务适合，无锁类如 AtomicInteger 也可以减少同步开销。
内存泄漏常见于资源释放和静态集合失控
Java 有 GC，不代表不会发生内存泄漏。尤其是以下两类问题很常见：
- 资源没有及时释放，应该使用
try-with-resources自动关闭。 static Map等静态集合持续增长，长期运行后会拖垮整个进程。
如果老年代长期居高不下，这一类代码问题通常值得优先排查。
高并发场景下，Debian 系统参数也要跟上
先提高文件描述符限制
很多 Java 服务一上并发，先撞上的不是 CPU，也不是堆内存，而是文件描述符上限。可以编辑 /etc/security/limits.conf，把 nofile 调整到 65535。修改后重新登录，或者临时执行：
ulimit -n 65535这一步对连接数高、线程多、IO 密集的服务尤其关键。
sysctl 参数主要影响连接队列、TIME_WAIT 和交换行为
可以在 /etc/sysctl.conf 中加入或调整以下参数：
net.core.somaxconn：增大 TCP 连接队列长度。net.ipv4.tcp_tw_reuse：复用TIME_WAIT状态连接。vm.swappiness=10：降低内存交换倾向，减少频繁 IO。
修改后通过下面的命令使配置生效：
sudo sysctl -p对于延迟敏感的 Java 服务来说，减少 swap 干扰通常比单纯调大 JVM 堆更直接。
文件系统和挂载选项也能补一点基础性能
文件系统方面，推荐使用 ext4 或 XFS。挂载时加上 noatime 选项，可以减少访问时间写回，虽然提升通常不算巨大，但在高频 IO 场景下属于成本较低的优化项。
没有监控就没有有效调优
先用 JDK 自带工具看堆、线程和 GC
VisualVM 和 JConsole 都是 JDK 自带工具，适合先做实时观察。直接运行以下命令即可启动：
jvisualvm
jconsole这类工具适合回答几个基础问题：堆是不是一直涨、线程数有没有异常、GC 是否过于频繁。很多情况下，先把现象确认清楚，后面的调参方向就已经明朗了。
GC 日志分析可以先用 grep 和 awk
并不是只有商业分析器才能看出问题。对于多数场景，用 grep 和 awk 先把 GC 日志里的频率、耗时和老年代回收占比提取出来，就足够做第一轮判断。只要发现异常，就回到 JVM 参数或代码层继续调整，再重新观察一轮结果。
复杂问题再上 JProfiler 和 YourKit
如果应用结构复杂，或者怀疑存在更隐蔽的热点与泄漏问题，可以进一步使用 JProfiler、YourKit 这类商业工具做深度分析。不过对大多数常规服务来说，免费工具加上 GC 日志，已经能覆盖主要调优需求。
更稳妥的调优顺序：先观测，再修改，再验证
在 Debian 上做 Java 优化，比较可靠的顺序是：先确认 JDK 与环境配置，再看堆和 GC，再回头检查代码对象分配与并发模型，最后补系统层参数。每次只改一组关键项，然后通过监控和日志验证结果，才能判断这次优化究竟是解决了问题，还是只是把问题换了个位置。
