为什么32位CPU/OS/Java上的Tomcat7比64位上的慢得多？

我正在做一个类似物联网的项目，需要测试一些使用Tomcat作为web服务器用Java实现的web前端在我们可能的硬件上是否“足够快”。我们需要在和之间做出选择。Pi3和C2都有一个64位CPU，根据它们的规格，性能略有不同，XU4只有一个32位CPU，理论上也应该和其他两个一样快。重要的是，Pi3默认运行a，即使它有64位CPU，XU4也运行32位，但C2运行64位操作系统，包括64位Java等

比较默认设置下的所有设备，我们发现C2的速度明显快于其他两种设备。用我们的一些测试应用程序重新启动Tomcat需要4分多钟，而不是30秒。此外，像

htop

这样的工具表明，运行时C2的大部分核心都被使用，而Pi3和XU4大部分只能加载一个核心。在Tomcat加载后，性能上的巨大差异也是一样的，我们可以浏览我们的测试应用程序：只需浏览一些CSS/JS页面，时间大约为1.5秒，而只需4到5.5秒

虽然Pi3的默认操作系统仅为32位，但我们成功地安装了一个特殊的64位SuSE发行版。猜猜发生了什么？虽然Pi3的时钟频率仅为C2的1,2 GHz，而C2的时钟频率仅为1,5 GHz，但性能与我们在C2上看到的性能非常接近，在许多测试中几乎相同。特别有趣的是，现在Pi3的所有核心大部分时间都处于负载状态，因此总体性能与C2非常相似

因此，只要切换到64位操作系统、Java等，我们就可以看到性能的显著提高。其他一切都是一样的，同样的测试应用程序，Tomcat等等，没有超频，没有其他存储或其他。这怎么可能？是什么导致了这种戏剧性的进步

使用64位操作系统，我们可以看到，与32位操作系统相比，设备的所有核心都更容易承受负载。但是为什么Linux内核调度器要关心它是在32位还是64位上运行这么多呢

如果没有，那么区别来自Java，为什么/如何？在这样一个简单的测试中，32位和64位JVM的性能不应该几乎相同吗？难道这两者不应该对内核施加几乎相同的负载，而不应该表现得那么不同吗？操作系统的架构不应该对JVM中使用的线程数量有任何影响，JVM主要由Tomcat和我们的测试应用程序控制，因此没有改变。根据我所读到的关于性能的内容，在我的用例中，差异应该可以忽略不计。此外，其他使用a的用户似乎没有我所看到的4到5的系数，单个内核的CPU负载差异也没有解释

我们的测试不受I/O限制，我们不分配太多内存，也不处理太多线程，几乎完全是CPU，只编译Java类并发布HTML、CSS和JS。但我们看到，根据32/64位的不同，内核上的负载也有很大不同，性能结果也有很大不同

我的一位同事说，他在某个地方读到，Java在内部仅使用64位值，因此在32位CPU/OS上需要更多的周期来处理相同的事情。我猜他的源并不意味着所有的东西，只是引用/指向内存的指针，比如对象。但我不能相信32位JVM在内部真的会无缘无故地使用64位指针，尤其是在存在类似优化的情况下。但这可能是个解释，有什么想法吗

与64位操作系统上的“arm64”相比，32位操作系统上的软件包都具有“”作为体系结构。我认为这可能会对Java的构建方式产生影响，也许真的因为某种奇怪的原因使用了64位指针

Java始终是OpenJDK 8，与操作系统的体系结构相同，并且与操作系统的包管理器提供的体系结构相同。带有SuSE的Pi3有1.8_144，UB为32位和64位安装提供1.8_131，都是服务器VM。此外，Linux内核是不同的，例如带有SuSE的Pi3与C2以及带有UB的XU 4:Pi3有一些当前的4.x，C2有一些旧的3.14，XU 4也有一些当前的4.9

---

那么，有没有关于差异来自哪里的想法？谢谢

您已经告诉我您是从标准软件包安装OpenJDK 8的

从来没有为ARM32优化过OpenJDK 8（至少在Debian和Ubuntu上）。默认包是从“零”端口构建的，该端口甚至没有JIT编译器

                        Raspberry Pi3   Raspberry Pi3   Odroid C2       Odroid XU4
                        1,20 GHz        1,20 GHz        1,5 GHz         2,0 GHz
                        Debian 32 Bit   SuSE 64 Bit     Ubuntu 64 Bit   Ubuntu 32 Bit
Start Apache Tomcat     04:30,00        00:29,06        00:27,45        04:08,39
1. page (1. request)    00:50,00        00:03,91        00:03,66        00:24,75
1. page (2. request)    00:03,30        00:00,79        00:00,77        00:02,39

尝试从手动安装Oracle JDK。
它内部有一个优化的热点JVM。而且它确实工作得更快

root@localhost:~# java -server -version
openjdk version "1.8.0_131"
OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-1~bpo8+1-b11)
OpenJDK Zero VM (build 25.131-b11, interpreted mode)
        ^^^^^^^                    ^^^^^^^^^^^^^^^^

---

相反，HotSpot JVM的Aarch64端口长期以来一直是OpenJDK的一部分。因此，在64位操作系统上，默认的OpenJDK包附带了HotSpot JVM，其中包括一个优化的JIT编译器。

您似乎没有指定要使用的JVM，更不用说是否（如果是HotSpot）在客户端或服务器模式下。我觉得有点好笑，链接部分右侧显示的选项有许多类似的问答。检查一下这个，另一个有趣的阅读是C。我要说的是，所有这些都指向一个简单的事实，在64位模式下运行会使大多数常见操作运行得更快。@Acewin它是链接的，因为我已经读过并提到了它？但这并不能解释为什么我看到内核上的负载非常不同，性能差异系数为4到5等等。你是否建议Tomcat和我的测试应用程序使用大量64位整数算法？@ThorstenSchöning这是一个相当主观的问题。实际上，你不能说智能手机中的2GHz处理器的性能与笔记本电脑中的2GHz处理器相同。由于操作系统或运行时级别的64位，所以添加的优化也是一样的。还有一点，32位和64位编译器生成的字节码是不同的。如果你

                        Raspberry Pi3   Raspberry Pi3   Odroid C2       Odroid XU4
                        1,20 GHz        1,20 GHz        1,5 GHz         2,0 GHz
                        Debian 32 Bit   SuSE 64 Bit     Ubuntu 64 Bit   Ubuntu 32 Bit
Start Apache Tomcat     04:30,00        00:29,06        00:27,45        04:08,39
1. page (1. request)    00:50,00        00:03,91        00:03,66        00:24,75
1. page (2. request)    00:03,30        00:00,79        00:00,77        00:02,39