jvm设计决策

Java还始终坚持它的整个库是“链接的”和可用的。因为它不使用DLL(它们不可能在每个平台上都可用),所以一切都必须由java加载和跟踪。

Java甚至自己做了很多浮点运算,因为FPU经常给出不同的结果,这被认为是不可接受的。

因此,如果你想一想C#可以委托给操作系统的所有东西,它与Java为操作系统所做的所有东西相关联,以补偿其他的东西,那么差异应该是意料之中的。

我现在已经在两个嵌入式平台上运行了java应用程序。一个是频谱分析仪,它在那里实际绘制了轨迹,另一个是机顶盒。

在这两种情况下,这个最小内存占用并不是一个问题——有一些特定于Java的问题,但不是一个问题。在这些情况下,实例化对象的数量和Swing绘制速度是更大的问题。

我不知道初始内存占用或Hello World应用程序的占用是否重要。差异可能是由JVM/CLR加载的库的数量和大小造成的。还可以为垃圾收集池预先分配一定量的内存。

我所知道的每个应用程序都使用了比Hello World更多的功能。这将在应用程序的整个执行过程中加载和释放数千次内存。如果您对JVM和CLR的内存利用率差异感兴趣,这里有几个链接,提供了一些有用的信息

http://benpryor.com/blog/2006/05/04/jvm-vs-clr-memory-allocation/

Memory Management Case study (JVM & CLR)

内存管理案例研究在Power Point中。非常有趣的介绍。

事实上的 记忆力

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
amwise   20598  0.0  0.5  22052  5624 pts/3    Sl+  14:59   0:00 mono Test.exe
amwise   20601  0.0  0.7 214312  7284 pts/2    Sl+  15:00   0:00 java Program

我用C#和Java编写了一个测试程序,打印字符串“test”并等待输入。我相信常驻集大小(RSS)值更准确地显示内存使用情况。虚拟内存使用(VSZ)的意义不大。

据我所知,it应用程序可以保留大量虚拟内存,而无需实际使用任何真实内存。例如,你可以问 VirtualAlloc 函数在Windows上保留或提交虚拟内存。

编辑:

这是一张来自我的windows box的漂亮图片: alt text http://awise.us/images/mem.png

每个应用程序都是一个简单的printf,后跟一个getchar。 Java和CLR使用了大量虚拟内存。C版本几乎不依赖任何东西,所以它的内存使用量相对较小。

我怀疑这两种情况是否真的重要。只需选择您更熟悉的平台,然后不要编写糟糕的、浪费内存的代码。我相信它会成功的。

编辑:

这 VMMap tool 来自微软的信息可能有助于确定内存的去向。

JVM统计其所有共享库,无论它们是否使用内存。

任务管理器在报告程序的内存消耗时相当不可靠。你应该把它作为指南。

Post Java 6u10似乎可以更智能地加载东西(它有一个jqs.exe=Java quick starter服务,可以将必要的数据保存在内存中并更快地启动),但Java 7被告知会更好。

Windows中的Process Explorer会正确报告专用字节(专用字节是那些没有被任何dll共享的内存区域)。

一个稍大的麻烦是,10年后,JVM仍然默认使用64MB内存。几乎每次都使用-Xmx真的很烦人,而且不能通过简单的双击在JAR中运行要求很高的程序(除非我更改文件扩展名分配的命令)。

CLR被计算为操作系统的一部分,因此任务管理器不会在应用程序进程下报告其内存消耗。