在 Debian 上进行 Java 编译性能测试
一 环境准备与基线
- 安装 JDK 并验证版本：sudo apt update && sudo apt install -y openjdk-11-jdk；执行 java -version 与 javac -version 确认输出正常。必要时设置环境变量：export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64 并加入 ~/.bashrc。为降低噪声，建议关闭省电/超线程干扰、固定 CPU 频率、停止无关服务，并使用一致的用户态环境（同一用户、同一工作目录、同一挂载选项）。为后续对比，先做一次“空编译”基线：记录 javac 自身开销（无文件或仅编译一个极小文件）。
二 方法一 命令行时间测量法（快速、可重复）
- 单文件快速测：time javac HelloWorld.java，记录 real/user/sys；重复多次取中位数。
- 项目级测（Maven）：使用 maven-compiler-plugin 固定编译参数，避免缓存干扰（clean 后编译），并多次运行取中位数。示例命令：
- mvn clean compile -DskipTests -Dmaven.compiler.fork=true -Dmaven.compiler.forceJavacCompilerUse=true
- 使用 time 统计总耗时；如需更稳健，循环执行 N 次并取 p50/p95。
- 项目级测（Gradle）：固定守护进程与并行度，避免首次解析开销影响。示例命令：
- ./gradlew --stop && ./gradlew compileJava --no-daemon -Porg.gradle.parallel=true -Porg.gradle.caching=true
- 同样用 time 统计，并循环多次取中位数。
- 要点：
- 固定编译参数（如 -source/-target、–release/-encoding、是否启用 AOT/分层编译等），确保对比公平。
- 避免增量编译干扰（clean 后编译），或明确区分“冷编译”与“增量编译”场景。
- 记录环境信息（JDK 版本、CPU/内存、磁盘类型、I/O 调度器、文件系统挂载选项）与编译命令，便于复现。
三 方法二 JMH 微基准测试法（面向“编译任务”的细粒度测量）
- 适用场景：当你希望把“编译”本身作为被测方法（例如在测试代码中调用编译器 API 或封装 javac 调用），用 JMH 获得统计学上更可靠的结果。
- 快速开始（Maven 原型）：
- mvn archetype:generate -DinteractiveMode=false
-DarchetypeGroupId=org.openjdk.jmh
-DarchetypeArtifactId=jmh-java-benchmark-archetype
-DgroupId=com.example -DartifactId=my-benchmark -Dversion=1.0
- 示例基准骨架（伪代码思路）：在 @Benchmark 方法中执行“编译一批源文件”的动作（如通过 javax.tools.JavaCompiler API 或执行外部 javac 子进程并等待），并在 @Setup/@TearDown 中准备/清理源码与输出目录。示例注解范式：
- @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.MILLISECONDS)
- @Warmup(iterations = 3, time = 1) @Measurement(iterations = 5, time = 1)
- @Fork(1) @State(Scope.Benchmark)
- 运行与输出：
- mvn clean install
- java -jar target/benchmarks.jar（可加 -rf json -rff result.json 导出结果，便于后续统计分析）
- 解读要点：关注 Score 的单位与分布，结合 p95/p99 判断稳定性；如需跨 JDK 或跨参数对比，保持相同样本与相同预热/测量设置。
四 结果记录与对比分析
- 建议记录的关键字段：
- 环境：JDK 版本与 vendor、CPU 型号与频率、内存容量、磁盘类型与调度器、文件系统、I/O 与 CPU 亲和性设置。
- 编译配置：Maven/Gradle 版本与插件配置、编译参数（-source/-target、并行度、是否增量）、是否使用构建缓存/守护进程。
- 指标：real/user/sys、编译吞吐（文件数/秒 或 LOC/秒）、失败/重试次数、GC 次数与时间（若用 JMH 可开启 GC 日志）。
- 分析方法：
- 每组场景至少重复 3–5 次，剔除异常点后取中位数；必要时给出 p95/p99。
- 对比“冷编译 vs 热编译”“并行 vs 串行”“不同 JDK/参数”的差异，并量化百分比变化。
- 若发现异常波动，结合系统监控（CPU 绑定、I/O 等待、内存与缓存命中）定位瓶颈。
五 常见陷阱与优化建议
- 避免“结果被构建缓存或守护进程污染”：Maven 使用 clean；Gradle 先 ./gradlew --stop；必要时禁用缓存进行对比测试。
- 控制 JIT 与系统噪声：JMH 场景保持足够预热；命令行场景尽量固定 CPU 频率与调度策略，避免后台任务干扰。
- 固定编译参数与源码规模：确保对比公平；若测试“增量编译”，需明确变更范围与方式。
- 资源争用：避免在同一台机器并行跑多组重负载测试；必要时绑定 CPU 亲和性，减少上下文切换与缓存抖动。
- 报告可复现：保存命令、版本与配置清单，便于他人复核与回溯。
