java：如何在32位JVM中使用超过4GB内存的堆

我们有一款产品目前运行在32位1.6 JRE上。我们使用的是Berkeley DB，它消耗了大约2.5 GB内存的4GB地址空间。这为JVM地址空间留下了大约750MB的内存

我们目前正在解决当前设置中的OfMemory问题。最好将JVM堆大小增加到1.5GB，同时仍保留Berkeley DB的2.5GB空间。有没有办法在32位JVM中访问超过4 GB的RAM/堆？我正在考虑以下解决方案
1） 使用一个GC性能更好的JVM——这将给我带来微乎其微的结果——我可以获得大约50-100 MB的工作内存
2） 类似于memcached或“进程外ehcache”——这可以让我在硬件允许的情况下获得IPC/序列化的开销

增加应用程序的可寻址内存还有其他解决方案吗

该解决方案应在运行sparc的solaris 10上运行

---

*更新：由于使用本机共享库，现在我们无法切换到64位JVM，即使操作系统是64位的*

---

谢谢，32位程序无法处理超过4GB的内存地址。它们只是没有足够的位来表示更多的内存

2^32=429497296

您最好升级到64位JRE

增加应用程序的可寻址内存还有其他解决方案吗

使用非共享内存（不是线程，而是进程）将单个应用程序拆分为多个进程。第一个进程可以运行DB，第二个进程可以运行项目的其他部分。您可以使用RMI或共享内存或套接字在进程之间进行通信

较低的内存，为操作系统保留。例如，在x86-32上，PAE允许操作系统保留小于1 GB的4 GB虚拟地址空间。（例如“4GB/4GB拆分”，在上受支持）

把一些数据放到磁盘上。该磁盘可以是RAM磁盘，速度更快；或者它可以是真正的磁盘，操作系统将使用“页面缓存”加速对文件的访问

而且，每一个真正的SPARC（不是古代的SuperSparc或可怜的人狮）都是64位的。因此，切换到64位版本的操作系统会更容易。我不知道Solaris，但在linux中，可以在64位操作系统上运行32位应用程序。64位操作系统将允许您运行64位JVM

更新：Solaris中有ramdisks，我认为您应该尝试使用它们来存储数据库（或数据库的临时文件）。

---

在第（1）种情况下，不会有额外的序列化/IPC；只有额外的读/写或mmap/munmap。但是Ramdisk的顺序比SSD快，比HDD快3-4个顺序。

我建议您在32位JVM中运行32位共享本机库，并在64位JVM中运行其他所有程序。您可以让64位JVM调用32位JVM来执行任何操作。我假设您的大部分数据/内存需求可以移动到64位JVM。

由于使用本机共享库，现在，即使操作系统是64位的，我们也无法切换到64位JVM-bit@anjanb：在这种情况下，您可能需要将应用程序拆分为多个进程，正如osgx建议的那样。由于使用本机共享库，目前，即使操作系统是64位的，我们也无法切换到64位JVM。您可以将本机库移动到单独的进程吗？您是否尝试在64位操作系统上运行32位JVM（这有助于不需要2/2或3/1 GB拆分）？有一个快速测试来检查内存拆分方案：-您可以在当前环境和64位操作系统+32位JVM组合中运行它如果他已经获得3.2gb的地址空间，他已经在运行的任何操作系统上使用了您的第二点（windows也有类似的功能）虽然我不明白为什么64位操作系统在这种情况下不给他整个32位地址空间-奇怪（）。我们在64位操作系统上运行32位JVM——solaris操作系统是solaris 64位，有大量GB RAM。只有java进程需要更多RAM/heap。anjanb，你能说BerkeleyDB的确切版本吗？BerkeleyDB保留了多少内存？这是我们必须进行试验的，看看它对吞吐量是否有意义对系统的期望。在同一台机器上的两个进程之间，您应该能够实现500 MB/s到3000 MB/s的吞吐量（取决于您的硬件）。你能建议64位Java应用程序与32位Java应用程序对话的最佳方法吗？我知道常用的unix/linux IPC机制，但在64位Java和32位Java场景中哪种机制最有效？JVM的位数应该无关紧要。我会使用使用使用阻塞IO或NIO的普通套接字可能是最简单的。你可以使用数据输出/输入带有IO的Stream或带有NIO的ByteBuffers。通过一个TCP连接，您可以每秒发送数百万条消息，往返延迟低于20微秒。