类似地，64位平台理论上最多可以支持2**64，或16EB。在这里，无论操作系统的存储容量是512MB还是2GB，都不会产生显著的影响。
但是，您的硬件可能会限制在44到56位之间(大多数当前系统是48位)，而44位只有256TB。
你的操作系统可能会把事情限制得更远。IIRC，最早的64位linux内核只使用40位(因为当时没有硬件可以使用更多)，只有1TB。
最后，在Windows上，如果你使用的是“basic”或“starter”版本，那么对于windows8homebasic版本，它可能会限制到8GB。这是唯一一个可能影响你的文件。
但是，与后来32位的情况不同，2018年几乎没有人拥有比他们的操作系统一次分页更多的物理RAM。很多人在内存超过4GB的机器上运行32位Windows(或者64位Windows上运行32位Python)，但是要在一个64位系统中加载一个40位有限操作系统的RAM超过1TB几乎是不可能的。
因此，无论您有多少RAM，您都应该能够将其大部分用于mmap。
有时，您希望mmap一个实际上无法放入RAM的文件。然后，您将依赖于操作系统的页面交换，这当然比窗口化更小的文件映射效率要低，但可能足够高效，而且可能要简单得多。
在这种情况下，它可能会在你的系统上工作，但是如果你不知道比你告诉我们的更多的信息，那就没有办法确定了。最简单的答案(和Python一样)是EAFP：尝试它，并准备处理它失败的异常(无论是通过编程方式，还是通过读取堆栈跟踪并搜索StackOverflow来寻找解决方案
进程间的通讯无非就是读写文件，socket通讯或者使用共享内存。 你不想用读写文件的方式，那就用共享内存或者socket通讯的方式。我个人觉得用socket比较简单，也许是因为我对socket比较熟悉。 下面是一篇java实现共享内存的文章，java没法管理内存，其实他也是靠创建映像文件来实现的。 共享内存在java中的实现 在jdk1.4中提供的类MappedByteBuffer为我们实现共享内存提供了较好的方法。该缓冲区实际上是一个磁盘文件的内存映像。二者的变化将保持同步，即内存数据发生变化会立刻反映到磁盘文件中，这样会有效的保证共享内存的实现。 将共享内存和磁盘文件建立联系的是文件通道类：FileChannel。该类的加入是JDK为了统一对外部设备（文件、网络接口等）的访问方法，并且加强了多线程对同一文件进行存取的安全性。例如读写操作统一成read和write。这里只是用它来建立共享内存用，它建立了共享内存和磁盘文件之间的一个通道。 打开一个文件建立一个文件通道可以用RandomAccessFile类中的方法getChannel。该方法将直接返回一个文件通道。该文件通道由于对应的文件设为随机存取文件，一方面可以进行读写两种操作，另一方面使用它不会破坏映像文件的内容（如果用FileOutputStream直接打开一个映像文件会将该文件的大小置为0，当然数据会全部丢失）。这里，如果用 FileOutputStream和FileInputStream则不能理想的实现共享内存的要求，因为这两个类同时实现自由的读写操作要困难得多。 下面的代码实现了如上功能，它的作用类似UNIX系统中的mmap函数。 // 获得一个只读的随机存取文件对象 RandomAccessFile RAFile = new RandomAccessFile(filename,"r")// 获得相应的文件通道 FileChannel fc = RAFile.getChannel()// 取得文件的实际大小，以便映像到共享内存 int size = (int)fc.size()// 获得共享内存缓冲区，该共享内存只读 MappedByteBuffer mapBuf = fc.map(FileChannel.MAP_RO,0,size)// 获得一个可读写的随机存取文件对象 RAFile = new RandomAccessFile(filename,"rw")// 获得相应的文件通道 fc = RAFile.getChannel()// 取得文件的实际大小，以便映像到共享内存 size = (int)fc.size()// 获得共享内存缓冲区，该共享内存可读写 mapBuf = fc.map(FileChannel.MAP_RW,0,size)// 获取头部消息：存取权限 mode = mapBuf.getInt()如果多个应用映像同一文件名的共享内存，则意味着这多个应用共享了同一内存数据。这些应用对于文件可以具有同等存取权限，一个应用对数据的刷新会更新到多个应用中。 为了防止多个应用同时对共享内存进行写操作，可以在该共享内存的头部信息加入写操作标志。该共享内存的头部基本信息至少有： int Length； // 共享内存的长度。 int mode// 该共享内存目前的存取模式。 共享内存的头部信息是类的私有信息，在多个应用可以对同一共享内存执行写操作时，开始执行写操作和结束写操作时，需调用如下方法： public boolean StartWrite() { if(mode == 0) { // 标志为0，则表示可写 mode = 1// 置标志为1，意味着别的应用不可写该共享内存 mapBuf.flip()mapBuf.putInt(mode)// 写如共享内存的头部信息 return true} else { return false// 指明已经有应用在写该共享内存，本应用不可写该共享内存 } } public boolean StopWrite() { mode = 0// 释放写权限 mapBuf.flip()mapBuf.putInt(mode)这个问题是错的, C++ 读取大文件比java慢是因为C++的代码写的有问题如果你直接用open， read这种流式设备的IO方式, 一个一个byte去读, c++ 比js都会慢, 因为getchar要不断的系统调用， 来回切换有大量开销, 所以建议一次读一个行或者一次读1m的数据.
另外java是空间换时间， 在read的时候先写内核缓存，然后一次装载到用户态，C++可以用std::filebuf这个来设置大小， 缓存越大， 内核切换的开销越小.
如果是几个G的文件， 你用java c 做stream IO都会慢的， 这是建议你直接把文件mmap到内存， 这也是大数据常用的手段。当然你的内存要足够大，要不然会内存颠簸
