1) 如果分配给应用程序的内存太小，将导致内存不足。JVM 不能及时释放内存空间给应用程序，最终将引发内存不足，或者JVM完全关闭。所以你必须提供更多的内存给应用程序。
2) 如果给对响应时间敏感的应用增加内存，如果不重启你的系统或者优化你的应用，Java堆最终会碎片化。当碎片发生时，可能会导致应用中断100毫秒~100秒，这取决与你的Java应用，Java堆的大小以及其他的JVM调优参数。
关于停顿的讨论大部分都集中在平均停顿或者目标停顿，很少涉及到堆压缩时的最坏停顿时间，在生产环境中堆中每千兆字节的有效数据的都将会发生大约1秒的停顿。
2~4秒的停顿对大多数企业应用来说都是不能接受的，所以尽管实际的Java应用实例可能需要更多的内存空间，但实际只分配2~4GB的内存。在一 些64位系统中带有很多关于伸缩性的JVM调优项，使得这些系统可以运行16GB乃至20GB的堆空间，并能满足典型响应时间的SLA。但是这些离现实较 远，JVM目前的技术无法在进行堆压缩时避免停顿应用程序。Java应用开发人员苦于处理这两个为我们大多数人所抱怨的任务。
l 架构/建模在大量的实例池之上，随之而来的是复杂的监控和管理操作。
l 反复的JVM和应用程序调优以避免“stop the world“引起的停顿。大多数程序员希望停顿不要发生在系统峰值负载期间。我称之为不可能的目标。