为什么Java的足迹如此之大？
Java——或者至少是Sun的Hotspot JVM——长期以来一直以内存占用量大而闻名。 究竟是什么让 JVM 享有如此盛誉？ 我对详细的细分感兴趣：有多少内存用于运行时（JIT？GC/内存管理？类加载器？）与 JNI/JVMTI 等“辅助”API 相关的任何内容？ 标准库？ （哪些部件得到多少钱？）还有其他主要部件吗？
我意识到，如果没有具体的应用程序加上虚拟机配置，这可能无法直接回答，因此至少要缩小范围：我主要对默认/典型虚拟机配置以及基线控制台“Hello world”应用程序感兴趣以及任何现实世界的桌面或服务器应用程序。 （我怀疑 JVM 占用空间的很大一部分在很大程度上独立于应用程序本身，理想情况下，我想放大这一部分。）
我还有其他几个密切相关的问题：
- <其他类似的技术，例如 .NET/mono，并没有表现出几乎相同的占用空间。 为什么会出现这种情况？
我在 intarwebs 上的某个地方读到，很大一部分占用空间仅仅是由于标准库的大小所致。 如果是这种情况，那么为什么要预先加载这么多标准库？
是否有任何努力（JSR，无论什么）来控制内存占用？ 我遇到的最接近的事情是一个减少 JVM 磁盘占用空间.
我确信在过去十年左右的时间里，Java 的每个新版本的足迹都发生了变化。 是否有任何具体的数字/图表准确记录了 JVM 的占用空间发生了多少变化？
Java - or at least Sun's Hotspot JVM - has long had a reputation for having a very large memory footprint. What exactly is it about the JVM that gives it this reputation? I'd be interested in a detailed breakdown: how much memory goes to the runtime (the JIT? the GC/memory management? the classloader?) anything related to "auxiliary" APIs like JNI/JVMTI? the standard libraries? (which parts get how much?) any other major components?
I realize that this may not be straightforward to answer without a concrete application plus VM configuration, so just to narrow things down at least somewhat: I'm primarily interested in default/typical VM configurations, and in a baseline console "Hello world" app as well as any real-world desktop or server app. (I'm suspecting that a substantial part of the JVM's footprint is largely independent of the app itself, and it is in this part that I'd like to zoom in, ideally.)
I have a couple of other closely related questions:
Other similar technology, such as .NET/mono, don't exhibit nearly the same footprint. Why is this the case?
I've read somewhere on the intarwebs that a large portion of the footprint is due simply to the size of the standard libraries. If this is the case, then why is so much of the standard libraries being loaded up front?
Are there any efforts (JSRs, whatever) to tame the memory footprint? The closest thing I've come across is a project to reduce the on-disk footprint of the JVM.
I'm sure that the footprint has varied over the past decade or so with every new version of Java. Are there any specific numbers/charts chronicling precisely how much the JVM's footprint has changed?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
一些举措：
Some initiatives:
我们有一些服务器端应用程序，它们除了桥接多播流量之外什么也不做（即它们没有永久状态）。 它们都在 32 位 Java6 (linux) JRE 上运行大约 2.3 - 2.5 Mb 堆。
这是一个很大的足迹吗？ 我可以轻松地在典型的服务器级计算机上拥有一千个这样的东西（从内存的角度来看），尽管这对于线程来说有点毫无意义 em> 观点！
也就是说，有 Jigsaw 项目 来模块化虚拟机（我相信是这些库） Java7 即将推出； 这将有助于那些希望减少占地面积的人。
我意识到这并不能真正回答你的问题，但它仍然是相关的！ 您在设计哪种类型的应用程序时发现内存占用是一个问题？
We have some server-side apps which do nothing but bridge multicast traffic (i.e. they have no permanent state). They all run with about 2.3 - 2.5 Mb of Heap on a 32-bit Java6 (linux) JRE.
Is this a big footprint? I could easily have a thousand of these on a typical server-class machine (from a memory perspective), although that would be bit pointless from a threading perspective!
That said, there is the Jigsaw project to modularize the VM (the libraries I believe) which is coming in Java7; this will help those who wish for smaller footprints.
I realize that this doesn't really answer your question but it is relevant nonetheless! What sort of applications are you designing where you are finding that memory footprint is an issue?
至少有一件事是 Java 的悠久历史 - 它始于 1995 年，现在是版本 6。在添加功能的同时保持向后兼容性不可避免地会扩大其足迹。 下图说明了很多...
At least one thing is Java's long history - it started in 1995 and is now version 6. Keeping backwards compatibility while adding features inevitably inflates its footprint. The image below tells pretty much...