关键不是压低单次批次大小，而是协同控制JVM堆与非堆内存、线程栈、直接内存及数据库连接缓冲，启用-XX:+UseContainerSupport与-XX:MaxRAMPercentage=70.0动态适配容器内存限制，并配合流式读取、游标分页、连接池限流和异步隔离，确保总内存不超限。

Java 批量数据库操作在 Docker 容器内存限额下平稳运行大导入，关键不是“压低单次批次大小”，而是让整个数据流不突破容器总内存边界——既要控 JVM 堆内占用，也要管住堆外开销、线程资源和数据库连接缓冲，同时避免全量加载到内存。

控制 JVM 内存，留足非堆空间

容器内存 = JVM 堆 + 元空间 + 线程栈 + 直接内存 + JVM 自身开销。只设 -Xmx1024m 而容器限制为 --memory=1g，大概率被 OOMKilled。

• 启用容器感知：-XX:+UseContainerSupport（JDK 8u191+ / JDK 10+ 默认开启）
• 动态分配堆：-XX:MaxRAMPercentage=70.0（例如 1GB 容器 → 堆约 716MB），再配 -XX:InitialRAMPercentage=70.0 避免启动期扩容
• 限制元空间：-XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=256m
• 压缩线程栈：-Xss256k（默认 1MB，批量任务常启数十线程，省出上百 MB）
• 约束直接内存：-XX:MaxDirectMemorySize=128m（尤其用 MyBatis Batch、Netty 或 HikariCP 的 connection pool 时必加）

分批 + 流式读取，拒绝全量加载

千万级导入若先 listAll() 加载进 ArrayList，哪怕堆够也会因对象头、引用、GC 压力触发 OOM。必须绕过“全量内存驻留”。

minimax-mcp-docker版（适配极空间）

MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。

下载

• 用 JDBC 流式游标：statement.setFetchSize(Integer.MIN_VALUE) + ResultSet.TYPE_FORWARD_ONLY，逐行或小批拉取
• 禁用传统 LIMIT/OFFSET 分页（大数据偏移性能崩塌），改用 游标分页（如 WHERE id > ? ORDER BY id LIMIT 1000）
• 每批处理 500–2000 条（依单条体积与 GC 表现调优），处理完立即 clear() 引用，促 Minor GC 回收
• 避免 ORM 全字段映射；用 Map<String, Object> 或自定义轻量 DTO，跳过代理、懒加载等额外对象

数据库侧协同降压

JVM 控好了，数据库端若没配合，照样拖垮容器：连接池撑满、事务日志暴涨、锁表阻塞。

立即学习“Java免费学习笔记（深入）”；

• HikariCP 设置合理连接数：maximumPoolSize ≤ 4（容器 CPU 限制为 2 核时），避免线程争抢和连接内存堆积
• 关闭自动提交，手动 每 100–500 条 commit 一次，平衡事务日志大小与回滚粒度
• 导入前临时 禁用非必要索引与外键检查（MySQL: SET FOREIGN_KEY_CHECKS=0；PostgreSQL: SET CONSTRAINTS ALL DEFERRED），导入完成后再重建
• 使用数据库原生批量工具兜底：如 MySQL 的 LOAD DATA INFILE（通过挂载 CSV 文件 + 容器内执行）、PostgreSQL 的 COPY FROM STDIN（JDBC 支持 copyIn() 流式写入）

异步化与资源隔离

大导入不该抢占主业务资源。在容器内也要做“轻重分离”。

• 导出/导入接口只触发任务，走 异步线程池（非 Tomcat 共享线程池），线程数设为 min(4, CPU核数×1.5)
• 专用数据源：配置只读副本库或独立连接池，与业务库物理/逻辑隔离
• 加内存熔断：用 MemoryUsageMonitor（如 Micrometer + JVM memory pools 指标）监听堆/元空间使用率，超阈值（如 85%）主动暂停批处理并告警
• Docker 启动时显式限制：--memory=1200m --memory-swap=1200m --cpus=2，并确保 JVM 参数与之对齐，避免“容器说 1G，JVM 当 8G 用”