SCCM环境下以SYSTEM身份运行Java安装程序的JVM内存报错问题

所有报错的本质和应用本身逻辑、普通用户下的运行兼容性无关，是SCCM调度SYSTEM身份进程的运行环境特性和JVM默认动态资源探测机制不匹配导致的：

• 第一阶段堆分配报错的原因
  初始启动参数只设置了-Xms512m初始堆大小，没有指定最大堆上限，JVM会自动按照当前系统物理内存的1/4计算最大堆值，也就是日志里看到的~1.9GB申请量。并行垃圾回收机制需要为这个堆申请一整块连续的位图内存做标记用。但SCCM下SYSTEM进程运行在隔离的Session 0环境，有严格的进程工作集内存配额，且虚拟地址空间被大量系统常驻进程碎片化，根本拿不出JVM默认要求的大块连续内存，所以直接在VM初始化阶段失败。
  这也是为什么同一份参数在普通用户身份下运行完全正常：普通用户进程运行在交互会话，不受Session 0的内存配额和地址空间碎片化影响。
• 调整GC后新报错的本质
  切换到串行GC、限制处理器数的操作，确实降低了GC本身的内存申请量，但没有解决核心问题：JVM依然会动态按照系统探测值，为CodeCache、Metaspace等内存区申请默认大小的连续内存块。
  日志里的CodeCache is full是JVM的误导性提示，实际日志已经明确标注了根因：used=3192Kb（仅用了3MB，远低于245MB的总上限），报错原因是not enough contiguous free space left——也就是进程的虚拟地址空间里，已经找不到足够大的连续空闲块来承载JVM默认预留的CodeCache区域，哪怕总空闲内存的绝对值完全够用。紧跟着出现的Metaspace OOM也是同一个连续内存块不足导致的分配失败。

不要靠调整GC类型碰运气，必须把所有JVM内存区域的大小显式写死，彻底关闭JVM的动态资源探测逻辑，降低连续内存块的申请要求，最终启动命令参考：

java -jar -Xms512m -Xmx768m \
  -Djna.nosys=true \
  -XX:+UseSerialGC \
  -XX:ActiveProcessorCount=1 \
  -XX:ReservedCodeCacheSize=64m \
  -XX:MaxMetaspaceSize=256m \
  -XX:CompressedClassSpaceSize=64m \
  myapp.jar [options]

核心调整点说明：

• 显式固定最大堆为768m，避免JVM动态申请1.9GB的超大连续堆空间
• 把CodeCache从默认的245MB压缩到64MB，大幅降低连续内存块的申请尺寸要求
• 给Metaspace、压缩类空间设硬上限，避免JVM动态扩容时申请大块连续内存
• 不要反向调大CodeCache参数，否则会进一步提高连续内存块的申请要求，反而更容易触发分配失败

内容的提问来源于stack exchange，提问作者tresf