猪八戒做网站排名,商品房交易网,企业手机网站建设市场分析,陈铭生怎么死的jvm7 jvm8即使在今天#xff08;2015年#xff09;#xff0c;我们仍然有两个版本或Oracle HotSpot JDK –已调整为32或64位体系结构。 问题是我们是否真的想在服务器甚至笔记本电脑上使用32位JVM#xff1f; 我们应该有很受欢迎的意见#xff01; 如果只需要较小的堆2015年我们仍然有两个版本或Oracle HotSpot JDK –已调整为32或64位体系结构。 问题是我们是否真的想在服务器甚至笔记本电脑上使用32位JVM 我们应该有很受欢迎的意见 如果只需要较小的堆则使用32位–它具有较小的内存占用空间因此您的应用程序将使用较少的内存并触发较短的GC暂停。 但这是真的吗 我将探索三个不同的领域 内存占用 GC性能 整体表现 让我们从内存消耗开始。 内存占用 众所周知32位和64位JVM之间的主要区别与内存寻址有关。 这意味着所有64位版本的引用都占用8个字节而不是4个字节。幸运的是JVM附带了压缩对象指针 默认情况下所有小于26GB的堆都启用该对象指针 。 只要32位JVM可以寻址2GB左右对于目标OS而言它仍然要少13倍左右那么这个限制对我们来说是可以接受的。 因此无需担心对象引用。 唯一不同的对象布局是标记标头它在64位上大4个字节。 我们还知道Java中的所有对象都是8字节对齐的因此有两种可能的情况 最糟糕的是– 64位对象比32位对象大8个字节。 这是因为向标头添加4个字节会导致对象被放入另一个内存插槽因此我们必须再添加4个字节来填充对齐间隙。 最佳–两个架构上的对象具有相同的大小。 当在32位上有4个字节的对齐间隙时就会发生这种情况可以通过其他标记头字节简单地填充它。 现在假设两种不同的应用程序大小来计算这两种情况。 装载了相当大项目的IntelliJ IDEA包含大约700万个对象这将是我们的较小项目。 对于第二个选项假设我们有一个大型项目我称其为“巨大”其中包含实时集中的5000万个对象。 现在让我们计算最坏的情况 IDEA - 7 millions * 8 bytes 53 MB Huge - 50 millions * 8 bytes 381 MB 上面的计算向我们显示在最坏的情况下IntelliJ会增加大约50MB的堆而对于某些带有很小对象的大型高度粒度的项目实际的应用堆会增加大约50MB。 在第二种情况下它可能占总堆的25左右但对于绝大多数项目而言它约为2几乎没有。 GC性能 这个想法是使用长键将800万个String对象放入Cache中。 一个测试包含4个调用这意味着有2400万次放入缓存映射。 我使用并行GC将总堆大小设置为2GB。 结果令人惊讶因为整个测试很快就在32位JDK上完成了。 3分40秒而64位虚拟机为4分30秒。 比较GC日志后我们可以看到差异主要来自GC暂停114秒到157秒。 这意味着实际上32位JVM带来的GC开销要低得多– 64位554可以暂停到618。 在下面您可以查看GC Viewer的屏幕截图两个轴上的缩放比例均相同 32位JVM并行GC 64位JVM并行GC 我原本希望64位JVM的开销较小但是基准测试表明即使总堆使用量在32位上也差不多我们在Full GC上释放了更多的内存。 年轻一代的停顿时间也相似–两种架构的停顿时间均为0.55秒左右。 但是平均主要停顿在64位上更高为3.2而32位上为2.7。 事实证明小堆的GC性能在32位JDK上要好得多。 问题是您的应用程序对GC的要求是否很高–在测试中平均吞吐量约为42-48。 在更多的“企业”场景中进行了第二次测试。 我们正在从数据库加载实体并在加载的列表上调用size方法。 对于大约6分钟的总测试时间对于64位我们有133.7s的总暂停时间对于32位我们有130.0s的总暂停时间。 堆的使用也非常相似– 64位为730MB32位JVM为688MB。 这向我们显示对于正常的“企业”用法在各种JVM架构上的GC性能之间没有太大差异。 从数据库中选择32位JVM并行GC 64位JVM并行GC从数据库中选择 即使具有类似的GC性能32位JVM仍可以在20秒前完成工作大约5。 整体表现 当然要验证适用于所有应用程序的JVM性能几乎是不可能的但是我将尝试提供一些有意义的结果。 首先让我们检查时间性能。 Benchmark 32bits [ns] 64bits [ns] ratioSystem.currentTimeMillis() 113.662 22.449 5.08
System.nanoTime() 128.986 20.161 6.40findMaxIntegerInArray 2780.503 2790.969 1.00
findMaxLongInArray 8289.475 3227.029 2.57
countSinForArray 4966.194 3465.188 1.43UUID.randomUUID() 3084.681 2867.699 1.08 正如我们所看到的与长变量相关的所有操作的最大且绝对明显的区别是。 在64位JVM上这些操作的速度是2.6到6.3倍之间。 使用整数非常相似生成随机UUID的速度也快7左右。 值得一提的是解释代码-Xint具有相似的速度-仅64位版本的JIT效率更高。 那么有什么特别的区别吗 是! 64位体系结构带有JVM使用的其他处理器寄存器。 检查生成的程序集后看起来性能提升主要来自使用64位寄存器的可能性这可以简化长时间的操作。 可以在Wiki页面下找到任何其他更改。 如果要在计算机上运行此程序则可以在我的GitHub上找到所有基准测试– https://github.com/jkubrynski/benchmarks_arch 结论 在整个IT世界中我们不能简单地回答-“是的您应该始终使用** bits JVM”。 这在很大程度上取决于您的应用程序特征。 如我们所见32位和64位体系结构之间存在许多差异。 即使长期相关操作的JIT性能提高了几百个百分点我们也可以看到经过测试的批处理过程在32位JVM上更早完成。 结论–没有简单的答案。 您应该始终检查哪种架构更适合您的要求。 非常感谢Wojtek Kudla审阅本文并执行其他测试:) 翻译自: https://www.javacodegeeks.com/2015/05/do-we-really-still-need-a-32-bit-jvm.htmljvm7 jvm8
