请翻译：The amount of CPU available to a container directly affects the startup time of a JVM-based application like Spring Boot In fact the JVM leverages as much CPU as available to run the initializatio

可用于容器的CPU数量直接影响基于JVM的应用程序（如Spring Boot）的启动时间。实际上，JVM利用尽可能多的CPU并发运行初始化任务，以减少启动时间。在启动阶段之后，应用程序将使用更低的CPU资源。

一种常见的策略是使用应用程序在正常情况下使用的CPU请求（resources.requests.cpu）来定义CPU请求，以便始终保证具有正确运行所需的资源。然后，根据系统，您可以决定指定较高的CPU限制或完全省略它（resources.limits.cpu），以优化启动性能，使应用程序可以使用节点上此刻可用的尽可能多的CPU。

CPU是可压缩资源，这意味着容器可以消耗尽其可用的CPU。当达到限制（由于resources.limits.cpu或节点上没有更多CPU可用）时，操作系统会开始限制容器进程，使其继续运行但可能性能较低。由于可压缩性，有时不指定CPU限制可以是一种有效的选择以获得性能提升。然而，您可能需要考虑具体情况并评估此决策的后果。

与CPU不同，内存是不可压缩资源。如果容器达到限制（由于resources.limits.memory或节点上没有更多内存可用），基于JVM的应用程序将抛出可怕的OutOfMemoryError，并且操作系统将以OOMKilled（OutOfMemory killed）状态终止容器进程。没有限制。因此，设置正确的内存值尤为重要。推断正确的配置没有捷径；您必须在正常情况下监视应用程序的运行。这对于CPU和内存都是如此。

找到应用程序所需的适当内存量后，我建议您同时将其用作请求（resources.requests.memory）和限制（resources.limits.memory）。这样做的原因与JVM的工作方式以及JVM堆内存的行为密切相关。动态增加和缩小容器内存将影响应用程序的性能，因为堆内存根据容器可用的内存进行动态分配。使用相同的值作为请求和限制可以确保始终保证固定数量的内存，从而获得更好的JVM性能。此外，它允许Paketo Buildpacks提供的Java内存计算器以最高效的方式配置JVM内存。

我已经多次提到了Java内存计算器。下一节将详细介绍这个主题。

Spring Boot插件用于Gradle/Maven的Paketo Buildpacks在构建Java应用程序的容器镜像时提供了一个Java内存计算器组件。该组件实现了一个算法，多亏了Pivotal（现在是VMware Tanzu）在云中运行容器化Java工作负载的经验，该算法经过多年的改进和改善。

在生产场景中，对于大多数应用程序来说，默认配置是一个不错的起点。但是，对于本地开发或演示，它可能需要太多资源。减少JVM线程数是使JVM消耗更少资源的一种方法，可以将默认的250个JVM线程数降低。因此，我们一直在使用BPL_JVM_THREAD_COUNT环境变量为Polar Bookshop中的两个基于Servlet的应用程序（Catalog Service和Config Service）配置较少数量的线程。响应式应用程序已经配置了较少的线程，因为它们比命令式应用程序更节省资源。因此，我们没有为Edge Service、Order Service或Dispatcher Service自定义线程数。

Paketo团队正在努力扩展Java内存计算器，以提供一个低配置模式，这在本地工作或低负载应用程序上非常有用。将来，可以通过标志来控制内存配置模式，而不必调整各个参数。您可以在Paketo Buildpacks的GitHub项目（http://mng.bz/5Q87）中找到有关此功能的更多信息。

JVM有两个主要的内存区域：堆和非堆。计算器专注于根据特定公式计算不同的非堆内存部分的值。剩余的内存资源分配给堆。如果默认配置不够好，可以根据自己的喜好进行自定义。例如，我在处理使用Redis进行会话管理的命令式应用程序时遇到了一些内存问题。它需要更多的直接内存，而默认配置的直接内存不足。在这种情况下，我通过JAVA_TOOL_OPTIONS环境变量使用了标准的-XX:MaxDirectMemorySize=50M JVM设置，并将直接内存的最大大小从10 MB增加到50 MB。如果您自定义特定内存区域的大小，计算器将相应地调整其他区域的分配。

JVM中的内存处理是一个有趣的主题，需要一本专门的书来全面介绍。因此，我不会详细介绍如何配置它。

由于我们正在为生产配置部署，让我们使用更合适的数字（例如100）来更新Catalog Service的线程计数。在实际场景中，我建议以250作为基准值开始。对于Polar Bookshop，我试图在展示实际生产部署外观和最小化您需要消耗（可能需要支付）的公共云平台资源之间做出妥协。

在部署应用程序到生产环境之前，我们需要进行的最后一个配置更改。接下来，我们将进行部署