只是试图理清我在这里的一个小分档。
目前，我正在开发一个涉及将文件列表收集到内存中的应用程序，以便删除。现在，在这一点上，我认为java.io.File数组可能会占用太多内存，因为此上下文中的Files列表可能包含数百个可能的条目。
我没有使用File对象列表占用过多的内存，而是认为收集文件名列表并将它们存储为java.lang.String对内存来说会更便宜。现在，这是我的问题：要记住这些文件要删除，哪些文件会更便宜：
我想尽可能快地制作程序，因此任何一种方法都有其优点，我只是想看看哪些方法的开销最小。提前谢谢！
答案 0 :(得分：14)
java.io.File表示文件系统中条目的文件名信息/元数据，它不包含文件的内容。
换句话说，像new File("somelarge.txt")这样的代码不会将somelarge.txt文件加载到内存中。
每个File对象包含的唯一真实数据是文件的String path（以及transient int prefixLength） - 认为File类仅仅是String path的包装器知道如何调用所有文件系统操作。
除了其他一些要求之外，这里的最佳选择是最容易阅读的代码并最好地传达您的意图。
答案 1 :(得分：2)
我不想变得粗鲁，但让我首先引用“不惜一切代价避免过早优化”的口头禅。您的代码性能是否敏感？你有内存使用限制吗？循环中没有数百个File个对象或数百个File个对象创建听起来很糟糕。尽管如此，如果您真的想要优化，请使用Profiler并使用这两种策略运行一些基准测试。我个人推荐Netbeans Profiler。
答案 2 :(得分：2)
File主要是String的包装器，比String本身消耗多达32个字节。如果你的服务器中有1000个内存成本约为70美元/ GB，那么它所消耗的额外内存价值约为0.22美分。如果你是最低工资，这大约相当于你的1秒钟。
除非你有一个内存有限的设备，否则你可能不必担心消耗少于1 MB的任何东西。
答案 3 :(得分：0)
现在，在这一点上，我想到了 可能需要java.io.File数组 内存太多，自列表以来 此上下文中的文件可能位于 数百个可能的条目。
除非您正在使用严重缺乏资源的系统，否则您不会遇到您认为存在的问题。
请记住，Java File对象只是“文件和目录路径名的抽象表示”。因此，它代表任何文件的固定内存成本，无论多大。如果您只处理数百个文件，那么几乎肯定不会对堆空间有任何限制。
如果您使用分析和监视创建解决方案并发现您面临内存限制，则此实现是您应该查看的最后一个位置。它的记忆力并不多。
因此，简而言之，您应该编写您最了解并且将来能够维护的代码。简单的代码就是你的朋友。
答案 4 :(得分：0)
话虽如此，一个String对象数组在内存和速度方面击败了File对象数组。这有几个原因：
File对象有许多私有属性，包括但不限于
私有字符串字段属性
文件系统特定前缀的transient前缀长度字段
File对象实例化依赖于对java.io.FileSystem的具体实现的静态引用，File构造函数对其进行调用
因此，创建 n 文件实例数组的成本等于
n * (expense_of_constructor + avg_construction_of_individual_path_strings_off_filesystem)
expense_of_constructor = init_of_local_vars + expense_of_path_normalization + expense_of_prefix_length_computation
使用 n 字符串路径名数组，成本只是
n * (avg_construction_of_individual_path_strings_off_filesystem)
就空间而言， n File对象数组的内存占用量为：
n * (avg_string_path_size + 32_bits_of_prefix_length + size_of_File_object_itself)
而 n String对象的数组将是
n * avg_string_path_size
为了简单和方便，我会使用一系列字符串。我甚至不打算做任何估计。在大多数情况下，更简单往往更好。只有当你使用非常有限的设备（例如手机）时，这个细节才会很重要。