Java，Go和Rust之间的比较( 二 ) _Java

我使用的Docker映像的命名约定为{lang} / webservice 。该应用程序的Java，Go和Rust版本的图像大小分别为113、8.68和4.24 MB 。

文章插图
> Final Docker images size

/ fibonacci / {number}
该端点接受段路径参数{number}，并返回斐波纳契数和序列化为JSON格式的输入数。
对于此特定端点，我选择以递归形式实现它。我毫不怀疑，迭代实现会产生更好的性能结果，并且出于生产目的，应该选择一种迭代形式，但是在生产代码中有些情况下必须使用递归（不是专门用于计算第n个斐波那契数））。因此，为此，我希望该实现大量涉及CPU堆栈分配。

文章插图
> CPU usage while hitting the /fibonacci endpoint

文章插图
> Memory usage while hitting the /fibonacci endpoint

文章插图
> Requests per second while hitting the /fibonacci endpoint

在Fibonacci端点测试中，Java实现是唯一一个对150个请求超时的实现，如下wrk的输出所示。

文章插图
> Timeouts

文章插图
> Latency for the /fibonacci endpoint

/ greeting / {name}
该端点接受段路径参数{name}，然后格式化字符串" Hello，{name}！"，进行序列化并将其返回为JSON格式的问候消息。

文章插图
> CPU usage while hitting the /greeting endpoint

文章插图
> Memory usage while hitting the /greeting endpoint

文章插图
> Requests per second while hitting the /greeting endpoint

结论

文章插图
> How the three languages compare

在得出任何结论之前，我想指出这三种语言之间的关系（或缺乏）。Java和Go都是垃圾收集语言，但是Java会提前编译为在JVM上运行的字节码。当启动Java应用程序时，即时（JIT）编译器将被调用，以通过随时随地将其编译为本机代码来优化字节码，以提高应用程序的性能。
Go和Rust都提前编译为本地代码，并且在运行时不会进行进一步的优化。
Java和Go都是垃圾收集语言，具有世界末日的副作用。这意味着，每当垃圾收集器运行时，它将停止应用程序，进行垃圾收集，并在完成后从停止的地方恢复应用程序。大多数垃圾收集器需要停止运行，但是有些实现似乎不需要这样做。
当Java语言在90年代创建时，其最大的卖点之一是一次编写，可在任何地方运行。当时，这很棒，因为市场上没有很多虚拟化解决方案。如今，大多数CPU支持虚拟化，这种虚拟化仅在代码可以在任何地方（无论如何在任何受支持的平台上运行）的前提下，才停止使用某种语言进行开发的诱惑。Docker和其他解决方案以便宜的价格提供虚拟化。
在整个测试中，应用程序的Java版本比Go或Rust对应版本消耗了更多的内存，在前两个测试中，Java使用的内存大约增加了8000％。这意味着对于实际应用程序，Java应用程序的运行成本会更高。
对于前两个测试，Go应用程序使用的CPU比Java少20％，同时处理38％的请求。另一方面，Rust版本使用的CPU比Go减少了57％，而处理的请求却增加了13％。
第三次测试在设计上是占用大量CPU的资源，因此我想从中挤出CPU的每一分。Go和Rust都比Java使用了1％的CPU 。而且我认为，如果wrk不在同一台计算机上运行，则所有这三个版本都会使CPU上限为100％。在内存方面，Java使用的内存比Go和Rust多2000％。Java可以处理的请求比Go多出20％，而Rust可以处理的请求比Java多出15％。
在撰写本文时，Java编程语言已经存在了将近30年，这使得在市场上寻找Java开发人员变得相对容易。另一方面，Go和Rust都是相对较新的语言，因此与Java相比，自然而然的数量或更少的开发人员。不过，Go和Rust都获得了很大的吸引力，许多开发人员正在将它们用于新项目，并且有许多使用Go和Rust的生产中正在运行的项目，因为简单地说，就资源而言，它们比Java更有效。需要。（也许是因为它们是街上的新酷语言！）