Java 在分配字节数组之前,请检查内存是否足够

Java 在分配字节数组之前,请检查内存是否足够,java,Java,我需要把一个文件载入内存。在我这样做之前,我想确保我的虚拟机中有足够的内存。如果不是,我想显示一条错误消息。我想避免OutOfMemory异常 方法: 获取我的文件的文件大小 使用Runtime.getRuntime().freemory() 检查是否合适 这行得通吗?或者你还有其他建议吗?任何“先检查后执行”策略的问题在于,在“检查”和“执行”之间可能会发生变化,从而使整个事情变得毫无用处 “尝试然后恢复”策略几乎总是一个更好的主意,不幸的是,这意味着尝试分配内存和处理异常。即使您选择了“先检

我需要把一个文件载入内存。在我这样做之前,我想确保我的虚拟机中有足够的内存。如果不是,我想显示一条错误消息。我想避免
OutOfMemory
异常

方法:

  • 获取我的文件的文件大小
  • 使用
    Runtime.getRuntime().freemory()
  • 检查是否合适
  • 这行得通吗?或者你还有其他建议吗?

    任何“先检查后执行”策略的问题在于,在“检查”和“执行”之间可能会发生变化,从而使整个事情变得毫无用处

    “尝试然后恢复”策略几乎总是一个更好的主意,不幸的是,这意味着尝试分配内存和处理异常。即使您选择了“先检查”选项,您仍然应该编码分配可能失败的可能性

    一个典型的例子是在打开文件之前检查文件是否存在。如果有人在您的检查和打开之间删除该文件,无论该文件最近是否存在,您都会得到一个异常

    现在我不知道你为什么不喜欢抓住这个例外,但我敦促你重新考虑一下。由于Java严重依赖它们,如果您不能真正控制正在尝试的内容(例如打开文件或分配内存),它们通常被认为是一种很好的方法


    从您的评论中可以看出,如果您担心内存不足会影响其他线程,那么如果您尝试为文件分配一个大区域,情况就不应该如此。如果您只剩下400米,而您要求600米,您的请求将失败,但您仍应拥有400米

    只有当你一分钱一分钱地努力达到极限(比如尝试600个独立的1M分配),其他线程才会在你完成大约400个任务后开始感到压力。而这只有在你不急于释放那400人的情况下才会发生

    所以,也许有一种可能是计算出你需要多少空间,并确保你一次就分配好了。要么行,要么不行。如果没有,您的其他线程也不会变得更糟


    如果你真的关心的话,我想你可以使用你建议的方法来尝试并确保分配给其他线程留下一点空间(比如100米或10%之类的)。但我还是会继续努力的。如果您的其他线程由于内存不足而无法完成其工作,那么有很多先例可以告诉用户为VM提供更多内存。

    我个人建议不要将大量文件直接加载到内存中,而是尝试将其分块加载或使用某种临时文件来存储中间数据。

    您可能需要查看
    FileChannel.map(FileChannel.MapMode,long,long)
    方法。这允许映射文件(想想POSIX
    mmap
    ),而无需填充堆。操作系统将(希望成功地)为您处理内存。

    但如果我的内存不足,它也会损坏所有其他线程,不是吗?我真的很想避免陷入困境OutOfMemory@matthias:不应该。如果您试图分配一个巨大的1G结构,但只有4亿可用空间,那么分配将失败,您仍然有4亿可用空间。仅当您尝试1000个单独的1M分配(例如,其中只有前400个可以工作)时,其他线程可能会遇到麻烦(除非您释放了400M quick smart)。