win10/win11批量新增模型崩溃主因是jvm堆内存瞬时打满且windows虚拟内存分配失败；应分批提交（每50条一组）、禁用内存压缩、调优jvm参数（如-xmx4g -xx:+useg1gc）、停用sysmain/wsearch服务，并将pagefile.sys迁移至非系统盘。
在Win10/Win11系统中执行模型批量新增（如调用saveAll方法插入数百条以上数据）时，程序突然崩溃并弹出“内存溢出”错误提示，根本原因是JVM或.NET运行时堆内存被瞬时打满，而Windows系统未能及时分配足够虚拟内存进行交换，导致进程被强制终止。
控制单批数据量并分段提交
这是最直接有效的规避手段。saveAll底层通常会将全部实体一次性加载进内存构建SQL或序列化结构，不加限制极易触达JVM默认堆上限（如-Xmx512m）。
第一步：将原始List
第二步：对每个子列表单独调用saveAll，两次调用之间插入Thread.sleep(10)——这并非为了延时，而是给JVM GC线程留出响应窗口，避免连续强引用阻塞回收。
第三步：若使用Spring Data JPA，务必确认未开启spring.jpa.open-in-view=true，否则HTTP请求生命周期内PersistenceContext持续持有一级缓存，分批也无效。
调整JVM堆参数并禁用内存压缩
Windows 10/11默认启用内存压缩（Memory Compression），它会把部分页面文件内容以LZ4算法压缩后驻留物理内存，看似节省实则干扰JVM的GC判断逻辑，尤其在saveAll触发大量对象创建时，压缩/解压开销反成瓶颈。
方法一：关闭内存压缩功能
以管理员身份运行PowerShell，执行：Disable-MMAgent -MemoryCompression → 重启生效。
方法二：重设JVM启动参数
在IDEA或命令行启动脚本中，将-Xmx值设为物理内存的1/4且不超过8GB（例如16GB内存设为-Xmx4g），同时追加-XX:+UseG1GC -XX:MaxGCPauseMillis=200；【严禁设置-Xmx超过物理内存总量】，否则Windows会因无法提供足够pagefile空间而直接报OOM。
清理系统级内存干扰项
某些Windows服务会在saveAll执行期间后台抢占内存带宽，尤其是SysMain（Superfetch）和WSearch（Windows Search），它们会主动预读磁盘数据并锁定RAM页，与模型持久化争抢物理页帧。
① 按Win + R输入services.msc → 找到SysMain → 右键属性 → 启动类型改为“禁用” → 点击“停止”。
② 同样在服务管理器中定位WSearch → 停止并禁用；若开发环境依赖文件索引（如IDE全局搜索），可改用Everything替代，它不驻留内存。
③ 运行cleanmgr → 清理C盘“Windows更新清理”和“传递优化文件”，这两类缓存会占用数百MB不可换出内存，影响pagefile.sys的连续分配能力。
迁移并固化页面文件位置
当saveAll触发大量临时对象创建时，JVM需要频繁向操作系统申请内存页。若pagefile.sys位于C盘且碎片化严重，Windows可能无法快速分配连续扇区，直接返回ENOMEM错误。
方法1：迁移到高速非系统盘
右键“此电脑”→属性→高级系统设置→性能设置→高级→虚拟内存更改→取消自动管理→选中C盘→选择“无分页文件”→点击设置→再选中D盘（需为NTFS格式且剩余空间≥16GB）→自定义大小：初始24576，最大49152→设置→确定→重启。
方法2：强制重建pagefile.sys
完成迁移后，进入安全模式（Shift+重启→疑难解答→高级选项→启动设置→重启→按F4），在安全模式下删除C盘根目录下的pagefile.sys（需先取消隐藏受保护系统文件），重启后系统将按新配置重建干净页面文件。
