嗯，到目前为止，我将尝试总结答案。
JVM对其堆大小没有硬性限制是没有技术原因的。它本来可以不用一种语言实现的，实际上许多其他动态语言都没有这种语言。
因此，给JVM一个堆大小限制只是实现者的设计决定。再次猜测为什么这样做有点困难，并且可能没有单一原因。最可能的原因是它有助于通过内存泄漏保护系统免受Java程序的攻击，否则可能会耗尽所有RAM并导致其他应用程序崩溃或系统崩溃。
Sun可以省略该功能，而只是告诉人们使用OS本地资源限制机制，但是他们可能希望始终有一个限制，因此他们自己实现了它。无论如何，JVM需要知道任何此类限制（以适应其GC策略），因此使用OS本地机制将不会节省太多编程工作。
同样，有一个原因为什么这样的内置限制对JVM比不具有GC的“普通”程序（例如C / C ++程序）更为重要：
与具有手动内存管理的程序不同，使用GC的程序即使具有固定的输入数据，也实际上并没有明确定义的内存要求。它仅具有最低要求，即在给定时间点实际存在（可到达）的所有对象的大小之和。但是，实际上，程序将需要额外的内存来保存已失效但尚未GCed的对象，因为GC无法立即收集每个对象，因为这会导致过多的GC开销。因此，GC只会不时启动，因此堆上需要一定的“呼吸空间”，死掉的对象可以等待GC。
这意味着使用GC的程序所需的内存实际上是在节省内存和提高吞吐量（通过让GC减少运行频率）之间的折衷。因此，在某些情况下，将堆限制设置为低于JVM可能使用的限制可能是有意义的，因此以性能为代价来节省RAM。为此，需要一种方法来设置堆限制。
