我在我的应用程序中的FileChannel.MapMode.READ_WRITE模式下创建/使用内存映射文件。在应用程序的整个生命周期中创建和删除Thoses文件。
由于GC没有必要释放直接缓冲区_底层_底层操作系统缓冲区，我想知道操作系统的后果是什么，更具体地说是关于RAM的使用。
我了解＆＃34;虚拟记忆＆＃34;该过程仍然受到不必要的映射的污染，但是对实际的RAM使用有什么影响（我想在＃34; Resident Memory＆＃34中的缓冲区随着时间的推移而被刷新）。
似乎进程可以在操作系统级别（崩溃JVM）进行OOM（内存不足） - 而不是Java OOM（内存不足）（堆中仍有足够的空间）。
我在Linux 64位（3.13.0-68-generic / Ubuntu）框中使用Oracle JRE 1.8.0_66-b17。
答案 0 :(得分：1)
地址空间是一种可以独立（稍微）可用内存耗尽的资源。
使用磁盘支持的文件映射，您只消耗与页面缓存一样多的内存（缓存读取和等待写入的脏页）。但保留的地址空间是整个映射的大小。
您还会使用文件句柄，并且可能会先用完文件句柄。
Java在进行GC操作时会进行munmap映射 - 但是，这意味着它不会发生在GC的计划表上。这通常是可以的，只要它比分配地址空间更快地释放地址空间。但是很像文件描述符或任何其他有限资源，你肯定可以用完。
64位，需要一段时间。这在32位系统上更是一个问题。
由于依赖终结器并不是很好，因此有很多要求改进对映射的控制。但在不影响性能或安全性的情况下，做得更好真的很难。 To quote Sun's evaluation of the problem
映射的字节缓冲区上没有unmap（）方法，因为没有已知的方法 提供一个没有遇到不可逾越的安全性的技术 表现问题。