filechannel.map不能映射超过2gb文件，因mappedbytebuffer的capacity等字段为int类型，最大仅支持integer.max_value（约2gb），超限会抛illegalargumentexception。
为什么FileChannel.map不能直接映射超过2GB的文件
因为MappedByteBuffer继承自ByteBuffer，而ByteBuffer的容量（capacity）、位置（position）、限制（limit）等关键字段都是int类型，最大只能表示Integer.MAX_VALUE（约2GB）。即使底层操作系统支持更大的映射，Java API 层面也强制要求map()方法的size参数必须是int范围内的值——传入超过2147483647字节会直接抛出IllegalArgumentException。
安全分段映射的核心规则
每次调用map()时，必须确保传入的size ≤ Integer.MAX_VALUE，且不越界。实际操作中推荐留有余量，例如控制单段≤2GB（即2L * 1024 * 1024 * 1024），并动态计算剩余长度：
- 用
long offset记录当前已处理的字节数 - 计算本段大小：
long segmentSize = Math.min(2L * 1024 * 1024 * 1024, fileSize - offset) - 调用
channel.map(MapMode.READ_ONLY, offset, segmentSize)获取该段缓冲区 - 处理完立即丢弃对
MappedByteBuffer的引用（如置为null），避免长期持有导致native内存无法回收
读取过程中的关键注意事项
映射只是建立虚拟地址关联，并不立即加载全部数据到物理内存；访问某一页时才触发缺页中断并从磁盘加载。因此读取时仍需按需遍历buffer内容：
- 不要依赖
buffer.array()——只读映射返回的buffer通常不支持该方法，会抛UnsupportedOperationException - 使用
buffer.get(int index)或buffer.get(byte[] dst)逐字节/批量读取 - 每段处理完毕后调用
buffer.clear()或buffer.flip()无实际释放效果，仅重置buffer内部指针；真正释放依赖JVM GC对buffer对象的回收及底层页表清理 - 若需强干预释放（如长周期服务中防止OOM），可考虑反射调用
sun.misc.Cleaner，但属非标准做法，JDK版本兼容性差，不推荐生产环境使用
比内存映射更稳妥的替代方案
对于纯顺序读取、无需随机访问的大文件，传统NIO通道+堆外缓冲区往往更可控、更少陷阱：
- 用
FileChannel.read(ByteBuffer)配合固定大小（如8MB）的ByteBuffer循环读取 - 或使用
Files.newInputStream(path)+BufferedInputStream流式处理 - 若需高性能传输（如文件复制），优先选用
transferTo()并配合循环逻辑，它同样受2GB单次限制，但系统级零拷贝开销更低 - MD5等摘要计算场景，可边读边更新Digest，完全避开全量映射需求
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
