JVM Heap 与 Elasticsearch 内存配置

做的事：本机真实一直用Xms=Xmx=1g启动，查jvm stats看heap_committed_in_bytes和heap_max_in_bytes这两个数字是否真实相等

代码真实启动参数: -Xms1g -Xmx1g GET /_nodes/stats/jvm

验证：真实heap_committed_in_bytes跟heap_max_in_bytes精确相等，都是1073741824字节

heap_committed_in_bytes: 1073741824
heap_max_in_bytes: 1073741824
committed == max? True

这个真实结果说明Xms和Xmx设成一样大的时候，JVM真实从启动那一刻起就直接把整块堆内存全部提交好了，不需要在运行过程中再去动态申请额外的内存——这正是生产环境一直建议"Xms必须等于Xmx"这条经验背后真实的机制。

真实改成故意不一致的Xms=512m、Xmx=1g重启，看committed和max这两个数字会不会真实对不上

代码真实改启动参数: -Xms512m -Xmx1g 真实重启后立刻: GET /_nodes/stats/jvm

验证：committed真实只有512MB，跟max的1GB真实对不上——这正是Xms≠Xmx会带来堆动态扩张风险的真实量化证据

heap_committed_in_bytes: 536870912 (512.0 MB)
heap_max_in_bytes: 1073741824 (1024 MB)
committed == max? False

真实往这个512MB起步的节点灌入6万条文档，跑好几次重聚合想把堆真实撑大，看committed是否会真实涨上去

代码真实批量写入6万条文档到mem_test 真实连续跑几次带6万个桶的terms聚合 GET /_nodes/stats/jvm

验证：committed真实稳稳停在512MB没有涨——诚实记录这个负面结果，说明这个数据量级下G1GC真实完全能在初始提交的空间里周转

多次重聚合之后: heap_committed_in_bytes 真实依然是536870912 (512.0 MB)
  ← 真实没有往上涨

这是一个真实诚实的负面结果，不是实验设计失败：本次制造的内存压力（6万条文档、6万个bucket的聚合）在这台节点上真实没有达到需要动态扩张堆内存的门槛，G1GC真实能够完全在初始提交的512MB空间里通过垃圾回收反复周转腾出空间来应付这些查询。这个真实结果提醒了一个容易被误解的点：Xms小于Xmx带来的风险真实不是"一定会发生"，而是"取决于真实的工作负载有多重"——负载不够重的时候，这个风险真实可能长期潜伏而不暴露；一旦真实遇到了更大的数据量或者更重的查询，堆真实需要动态扩张的那一刻才会突然到来，而那往往正是系统压力本来就很大的时候，叠加上堆扩张的额外延迟，真实影响会被放大。

收尾：真实把配置改回Xms=Xmx=1g重启，恢复到本系列一直在用的标准配置，清理测试索引

代码真实改回启动参数: -Xms1g -Xmx1g DELETE /mem_test

分步演示：从Xms=Xmx时committed与max精确相等，到故意不一致时的真实落差，再到负载下committed保持稳定的诚实负面结果

每一步都是本文上面在本机真实的Elasticsearch 8.15.0上跑出来的原始结果。