0

我在 java web 应用程序中工作。在某些部分中，我使用了非常巨大的树变量，可以保存并保留在内存 (RAM) 中。我可以将它迁移到虚拟内存（交换）。注意：巨大的树包含在建议 Ajax 文本框中使用的所有用户的名称和电子邮件。

4

6 回答 6

3

Linux 中没有强制交换内存块的标准方法，因此 JVM 将无法要求操作系统执行此类任务。

如果您想要此功能，您可以做的最好的事情是序列化树并将原始数据写入磁盘文件，然后在您准备好时将其带回。

但是您可能不希望这样，因为与物理内存 i/o 相比，写入磁盘非常慢。

举个例子，让操作系统担心这一点。可以肯定的是，它知道比您更好的内存管理方法。

于 2009-10-01T21:40:21.337 回答
1

让您的用户正在使用的操作系统来处理这个问题。

于 2009-10-01T21:36:17.833 回答
1

您的操作系统会自动管理自己的内存并根据需要将内容推送到交换文件。

如果您有大量数据，您可能需要考虑将数据存储在数据库中，而不是巨大的内存树中。这可能使您的应用程序可以更好地扩展，并且还可以提高性能——它肯定会比在您需要查找或修改记录时将整个结构读取和写入磁盘时提供更好的性能。

编辑：您不一定要设置专用的数据库机器。鉴于您目前正尝试将所有数据存储在内存中，您可能可以使用HSQLDB或SQLite等可嵌入数据库，它们的大小限制分别为 16 GB 和 2Tb。

于 2009-10-01T21:40:38.357 回答
1

部分分页以进行交换的正在运行的 Java 映像是死 Java 映像。一旦足够热切的 GC 启动，您就可以将所有内容重新分页。分页已经够糟糕了。如果您实际上没有足够的 RAM 来处理整个事情，那么您最终会导致服务器崩溃、反应迟钝。分页 Java 很糟糕（tm）。

如果你有足够的内存来存储整个东西，你根本不需要交换。

将您的列表填充到磁盘上的数据库表中，对其进行索引，限制您的结果集，并对它进行适当的查询。这将是一个净赢，数据库可以缓存它最喜欢的页面，所以你不必考虑它。

或者获得更多内存。

于 2009-10-01T21:49:29.593 回答
1

我发现有趣的是每个人都告诉他将项目存储在磁盘上非常低效，同时建议他使用数据库，可能是一个远程数据库，将数据存储在磁盘上......在另一台机器上......

您假设系统在盲目处理交换文件时比让交换文件受知道未来情况的代码影响更有效。换出你知道一段时间内不会使用的内存比让系统查看内存中的所有项目并尝试有效地将其中一些放入该文件中要高效得多。

当然，虽然错了，但您都有些正确.. LOCAL 数据库是将数据存储到 FILE（将在其中写入和读取）的最有效方式。如果您无权访问本地数据库，请编写代码一。哈希图被设计为存储在内存中，而有序索引链表被设计为存储在磁盘上。尝试直接从内存推送到磁盘而不考虑两种介质的效率是无效的。

于 2010-02-18T16:07:28.470 回答
0

这作为对同一问题的不同看法如何：我在服务器端创建了很多 PDF，我有 1000 个客户通常希望在一个月的同一时间运行报告。平均 PDF 大小可能为 7-10Mb。在有限堆可用的情况下，将数据“交换”到临时文件是创建 PDF 的有效方式，因为我需要能够在将 PDF 数据流式传输到客户端之前设置响应的内容长度。

也许不仅仅是质疑设计，一些有用的选项可能会很方便。就我个人而言，我正在考虑每个进程使用一个临时文件或同时访问单个“交换”文件。

你有什么建议？

于 2010-08-17T21:34:25.387 回答