Java - 或者至少是Sun的Hotspot JVM - 长期以来因拥有非常大的内存占用而闻名。究竟是什么使JVM获得了这种声誉呢？我对详细的细分感兴趣：运行时（JIT？GC /内存管理？类加载器？）有多少内存与JNI / JVMTI等“辅助”API有关？标准库？ （哪些部分得到多少？）任何其他主要组件？
我意识到如果没有具体的应用程序和VM配置，这可能不是直截了当的，所以只是为了至少在某种程度上缩小范围：我主要对默认/典型VM配置以及基准控制台“Hello”感兴趣世界“应用程序以及任何真实的桌面或服务器应用程序。 （我怀疑JVM的大部分内容在很大程度上独立于应用程序本身，而且在这部分我想要放大，理想情况下。）
我还有其他一些密切相关的问题：
其他类似的技术，例如.NET / mono，并没有表现出几乎相同的足迹。为什么会这样呢？
我已经在intarwebs的某个地方读过，很大一部分足迹只是因为标准库的大小。如果是这种情况，那么为什么要预先加载这么多标准库？
是否有任何努力（JSR，无论如何）来驯服内存占用？我遇到的最接近的事情是reduce the on-disk footprint of the JVM项目。
我确信在过去的十年左右，每个新版本的Java都会有足够的变化。是否有任何特定的数字/图表精确记录了JVM的足迹变化多少？
答案 0 :(得分：7)
一些举措：
答案 1 :(得分：5)
我们有一些服务器端应用程序只能桥接多播流量（即它们没有永久状态）。它们都运行在32位Java6（linux）JRE上大约 2.3 - 2.5 Mb 的堆。
这是一个很大的足迹吗？在典型的服务器级机器上（从内存的角度来看），我可以很容易地拥有一千个，但这对于线程来说是没有意义的 em>观点！
也就是说，有Jigsaw project来模块化Java（我相信的库），它们将在Java7中出现;这将有助于那些希望缩小足迹的人。
我意识到这并没有真正回答你的问题，但它仍然是相关的！您在设计哪种应用程序时会发现内存占用问题？
答案 2 :(得分：0)
至少有一件事是Java的悠久历史 - 它始于1995年，现在是版本6.在添加功能的同时保持向后兼容性不可避免地会增加其占用空间。 This图片几乎可以说明......
