Why is the JVM slow to start?(为什么JVM启动慢?)
问题描述
与其他运行时(如 CPython)相比,究竟是什么让 JVM(尤其是 Sun 的实现)运行缓慢?我的印象是,这主要与加载大量库有关,无论它们是否需要,但这似乎不需要 10 年的时间来解决.
What exactly makes the JVM (in particular, Sun's implementation) slow to get running compared to other runtimes like CPython? My impression was that it mainly has to do with a boatload of libraries getting loaded whether they're needed or not, but that seems like something that shouldn't take 10 years to fix.
想一想,JVM 启动时间与 Windows 上的 CLR 相比如何?Mono 的 CLR 怎么样?
Come to think of it, how does the JVM start time compare to the CLR on Windows? How about Mono's CLR?
更新:我特别关注 Unix 中常见的链接在一起的小型实用程序的用例.Java 现在适合这种风格吗?无论 Java 产生什么启动开销,它是为每个 Java 进程加起来的,还是仅在第一个进程中真正体现出来?
UPDATE: I'm particularly concerned with the use case of small utilities chained together as is common in Unix. Is Java now suitable for this style? Whatever startup overhead Java incurs, does it add up for every Java process, or does the overhead only really manifest for the first process?
推荐答案
这是 维基百科必须要做的谈谈这个问题(附上一些参考资料).
Here is what Wikipedia has to say on the issue (with some references).
似乎大部分时间只是从磁盘加载数据(类)(即启动时间受 I/O 限制).
It appears that most of the time is taken just loading data (classes) from disk (i.e. startup time is I/O bound).
这篇关于为什么JVM启动慢?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持编程学习网!
本文标题为:为什么JVM启动慢?
基础教程推荐
- REST Web 服务返回 415 - 不支持的媒体类型 2022-01-01
- 无法复制:“比较方法违反了它的一般约定!" 2022-01-01
- RabbitMQ:消息保持“未确认"; 2022-01-01
- 如何对 Java Hashmap 中的值求和 2022-01-01
- 存储 20 位数字的数据类型 2022-01-01
- 问题http://apache.org/xml/features/xinclude测试日志4j 2 2022-01-01
- Spring AOP错误无法懒惰地为此建议构建thisJoinPoin 2022-09-13
- 修改 void 函数的输入参数,然后读取 2022-01-01
- 使用堆栈算法进行括号/括号匹配 2022-01-01
- Struts2 URL 无法访问 2022-01-01
