本指南介绍了针对使用 Java 编程语言编写的 Knative 服务服务的优化以及背景信息，以帮助您了解某些优化所涉及的权衡。此页面上的信息是对常规优化提示的补充，这些提示同样适用于 Java。
传统的 Java Web 应用旨在高并发和低延迟地处理请求，并且通常为长时间运行的应用。JVM 自身还会通过 JIT 逐渐优化执行代码，以使热路径得到优化，并使应用运行更加高效。
这些传统的 Java Web 应用中的许多最佳做法和优化都围绕着以下内容：
- 处理并发请求（基于线程的 I/O 和非阻塞 I/O）
- 通过使用连接池和批处理非关键函数减少响应延迟时间，例如将跟踪记录和指标发送到后台任务。
虽然这些传统优化中有许多非常适合长时间运行的应用，但对于 Knative 服务服务（仅在主动处理请求时运行）而言，效果可能不太理想。本页介绍了关于 Knative 服务的一些不同的优化和权衡，可用于减少启动时间和内存用量。
优化容器映像
通过优化容器映像，您可以缩短加载时间和启动时间。您可以通过以下方式优化映像：
- 尽可能减小化容器映像大小
- 避免使用嵌套库归档 JAR
- 使用 Jib
尽可能减小容器映像大小
请参阅有关尽可能减小容器映像大小的常规提示页面，了解此问题的更多背景信息。常规提示页面建议将容器映像大小减少为仅包含必需的内容。例如，确保容器映像不包含：
- 源代码
- Maven 构建工件
- 构建工具
- Git 目录
- 未使用的二进制文件/实用程序
如果您是从 Dockerfile 内构建代码，请使用 Docker 多阶段构建，以使最终容器映像仅具有 JRE 和应用 JAR 文件本身。
避免嵌套库归档 JAR
一些流行的框架（如 Spring Boot）会创建一个应用归档 (JAR) 文件，其中包含其他库 JAR 文件（嵌套 JAR）。这些文件需要在启动期间解压缩，并且可以提高 Knative 服务中的启动速度。尽可能使用外部化的库创建精简 JAR：这可以通过使用 Jib 将应用容器化来自动完成。
使用 Jib
您可以使用 Jib 插件创建最小容器并自动展平应用归档。Jib 同时支持 Maven 和 Gradle，并且可以为 Spring Boot 应用提供开箱即用的支持。某些应用框架可能需要额外的 Jib 配置。
JVM 优化
为 Knative 服务服务优化 JVM 可以提高性能和内存用量。
使用容器感知的 JVM 版本
在虚拟机和机器中，对于 CPU 和内存分配，JVM 会从常见位置（例如，Linux 中的 /proc/cpuinfo 和 /proc/meminfo）查找其可以使用的 CPU 和内存。但是，在容器中运行时，CPU 和内存限制条件存储在 /proc/cgroups/... 中。较旧版本的 JDK 会继续在 /proc（而不是 /proc/cgroups）中查找，这可能会导致 CPU 和内存用量超出分配的上限。这可能会导致：
- 线程过多，因为线程池大小由
Runtime.availableProcessors()配置 - 超出容器内存上限的默认最大堆。JVM 在进行垃圾回之前大量使用内存。这很容易导致容器超出容器内存限制，并导致 OOMKilled。
因此，请使用容器感知的 JVM 版本。默认情况下，大于或等于 8u192 的 OpenJDK 版本是容器感知的。
了解 JVM 内存用量
Java 内存用量由本机内存用量和堆用量组成。应用的工作内存通常位于堆中。堆的大小受最大堆配置的限制。使用提供 256MB RAM 实例的 Knative 时，您无法将全部 256MB 分配给最大堆，因为 JVM 和操作系统还需要原生内存，例如线程堆栈、代码缓存、文件句柄、缓冲区等。如果您的应用发生 OOMKilled，并且您需要了解 JVM 内存使用情况（原生内存 + 跟踪），请开启“原生内存”应用并成功退出。如果应用发生 OOMKilled，则无法输出信息。在这种情况下，请先使用更多内存运行应用，以便它可以成功生成输出。
您无法通过 JAVA_TOOL_OPTIONS 环境变量开启 Native Memory Tracking。您需要将 Java 命令行启动参数添加到容器映像入口点，以便您的应用使用以下参数启动应用：
java -XX:NativeMemoryTracking=summary \
-XX:+UnlockDiagnosticVMOptions \
-XX:+PrintNMTStatistics \
...
可以根据要加载的类的数量来估算本机内存用量。请考虑使用开源 Java 内存计算器来估算内存需求。
关闭优化编译器
默认情况下，JVM 有多个阶段的 JIT 编译。虽然这些阶段可以逐渐提高应用的效率，但它们也会增加内存使用的开销，并增加启动时间。
对于短期运行的无服务器应用（例如函数），请考虑关闭优化阶段，以牺牲长期效率换取更短的启动时间。
对于 Knative 服务服务，请配置以下环境变量：
JAVA_TOOL_OPTIONS="-XX:+TieredCompilation -XX:TieredStopAtLevel=1"
使用应用类数据共享
如需进一步减少 JIT 时间和内存用量，请考虑使用应用类数据共享 (AppCDS) 来共享预先编译的 Java 类归档。启动同一 Java 应用的另一个实例时，可以重复使用 AppCDS 归档。JVM 可以重复使用归档中预先计算的数据，从而缩短启动时间。
使用 AppCDS 时需注意以下几点：
- 要重复使用的 AppCDS 归档必须使用最初生成它的 OpenJDK 发行版、版本和架构来重现。
- 您必须至少运行一次应用以生成要共享的类列表，然后使用该列表生成 AppCDS 归档。
- 类的范围取决于应用运行期间执行的代码路径。为扩大范围，采用编程方式可以触发更多代码路径。
- 应用必须成功退出才能生成此类列表。请考虑实现用于表示 AppCDS 归档生成的应用标志，以便立即退出。
- 只有使用与生成 AppCDS 归档完全相同的方式来启动新实例，才能重复使用该归档。
- AppCDS 归档仅适用于常规 JAR 文件包；不支持使用嵌套 JAR。
使用阴影 JAR 文件的 Spring Boot 示例
Spring Boot 应用默认使用嵌套超级 JAR，这不适用于 AppCDS。因此，如果您要使用 AppCDS，则需要创建一个阴影 JAR。例如，使用 Maven 和 Maven Shade 插件：
<build>
<finalName>helloworld</finalName>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<configuration>
<keepDependenciesWithProvidedScope>true</keepDependenciesWithProvidedScope>
<createDependencyReducedPom>true</createDependencyReducedPom>
<filters>
<filter>
<artifact>*:*</artifact>
<excludes>
<exclude>META-INF/*.SF</exclude>
<exclude>META-INF/*.DSA</exclude>
<exclude>META-INF/*.RSA</exclude>
</excludes>
</filter>
</filters>
</configuration>
<executions>
<execution>
<phase>package</phase>
<goals><goal>shade</goal></goals>
<configuration>
<transformers>
<transformer implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
<resource>META-INF/spring.handlers</resource>
</transformer>
<transformer implementation="org.springframework.boot.maven.PropertiesMergingResourceTransformer">
<resource>META-INF/spring.factories</resource>
</transformer>
<transformer implementation="org.apache.maven.plugins.shade.resource.AppendingTransformer">
<resource>META-INF/spring.schemas</resource>
</transformer>
<transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer" />
<transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
<mainClass>${mainClass}</mainClass>
</transformer>
</transformers>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
如果您的阴影 JAR 包含所有依赖项，您可以在容器构建期间使用 Dockerfile 生成简单归档：
# Use Docker's multi-stage build
FROM adoptopenjdk:11-jre-hotspot as APPCDS
COPY target/helloworld.jar /helloworld.jar
# Run the application, but with a custom trigger that exits immediately.
# In this particular example, the application looks for the '--appcds' flag.
# You can implement a similar flag in your own application.
RUN java -XX:DumpLoadedClassList=classes.lst -jar helloworld.jar --appcds=true
# From the captured list of classes (based on execution coverage),
# generate the AppCDS archive file.
RUN java -Xshare:dump -XX:SharedClassListFile=classes.lst -XX:SharedArchiveFile=appcds.jsa --class-path helloworld.jar
FROM adoptopenjdk:11-jre-hotspot
# Copy both the JAR file and the AppCDS archive file to the runtime container.
COPY --from=APPCDS /helloworld.jar /helloworld.jar
COPY --from=APPCDS /appcds.jsa /appcds.jsa
# Enable Application Class-Data sharing
ENTRYPOINT java -Xshare:on -XX:SharedArchiveFile=appcds.jsa -jar helloworld.jar
关闭类验证
当 JVM 将类加载到内存中以供执行时，它会验证该类未被篡改并且没有恶意修改或损坏。如果您的软件交付流水线是可信的（例如，您可以验证每个输出），如果您完全信任容器映像中的字节码，并且您的应用未从任意远程来源加载类，则您可以考虑关闭验证。如果在启动时加载大量类，则关闭验证可能会提高启动速度。
对于 Knative 服务服务，请配置以下环境变量：
JAVA_TOOL_OPTIONS="-noverify"
减小线程栈大小
大多数 Java Web 应用都是基于每个连接一个线程的模式。每个 Java 线程都会消耗本机内存（而不是堆内存）。这称为线程栈，并且每个线程默认为 1 MB。如果您的应用处理 80 个并发请求，则它可能至少有 80 个线程，这相当于使用了 80 MB 的线程栈空间。该内存不计入堆大小。默认值可能大于必要值。您可以减小线程栈大小。
如果减小得太多，则将出现 java.lang.StackOverflowError。您可以对应用进行分析，并找到要配置的最佳线程栈大小。
对于 Knative 服务服务，请配置以下环境变量：
JAVA_TOOL_OPTIONS="-Xss256k"
减少线程
您可以通过使用非阻塞反应式策略和避免后台活动来减少线程数量，从而优化内存。
减少线程数量
由于线程栈，每个 Java 线程都可能会增加内存用量。Knative 服务允许最多 80 个并发请求。使用每个连接一个线程模式时，您最多需要 80 个线程来处理所有并发请求。大多数 Web 服务器和框架都允许您配置线程数和连接数上限。例如，在 Spring Boot 中，您可以在 applications.properties 文件中设置最大连接数：
server.tomcat.max-threads=80
编写非阻塞反应式代码以优化内存和启动
要真正减少线程数量，请考虑采用非阻塞反应式编程模型，以便在处理更多并发请求时可以显著减少线程数量。Spring Boot Webflux、MicrosoftNavt 和 Quarkus 等应用框架支持反应式 Web 应用。
Spring Boot Webflux、Micronaut、Quarkus 等反应式框架通常具有更快的启动时间。
如果您继续在非阻塞框架中编写阻塞代码，Knative 服务服务中的吞吐量和错误率将显著下降。这是因为非阻塞框架将只有几个线程，例如 2 个或 4 个。如果您的代码被阻塞，则仅可以处理极少的并发请求。
这些非阻塞框架还可以将阻塞代码分流到无界限线程池，这意味着，虽然它可以接受许多并发请求，但阻塞代码将在新线程中执行。如果线程以无界限的方式累积，则会耗尽 CPU 资源并开始抖动。延迟时间将受到严重影响。如果您使用非阻塞框架，请务必了解线程池模型并相应地绑定池。
避免后台活动
当该实例不再收到请求时，Knative 服务会限制实例 CPU。包含后台任务的传统工作负载在 Knative 服务中运行时需要特别注意。
例如，如果您要收集应用指标并在后台批处理指标以进行定期发送，则在 CPU 受到限制时，这些指标不会发送。如果您的应用不断收到请求，您可能会看到较少的问题。如果您的应用具有较低的 QPS，则后台任务可能永远不会执行。
以下是您需要注意的一些在后台运行的常见模式：
- JDBC 连接池 - 清理和连接检查在后台进行
- 分布式跟踪记录发送器 - 分布式跟踪记录通常会定期或在后台缓冲区已满时进行批处理和发送。
- 指标发送器 - 指标通常会在后台进行批量处理和发送。
- 对于 Spring Boot，任何带有
@Async注解的方法 - 计时器 - 任何基于计时器的触发器（例如，ScheduledThreadPoolExecutor、Quartz 或
@ScheduledSpring 注解）可能无法在 CPU 受到限制时执行。 - 消息接收器 - 例如，Pub/Sub 流式拉取客户端、JMS 客户端或 Kafka 客户端，通常在后台线程中运行，无需请求。当您的应用没有请求时，它们将不起作用。在 Knative 服务中，不建议以这种方式接收消息。
应用优化
在 Knative 服务服务代码中，您还可以进行优化，以缩短启动时间并降低内存用量。
减少启动任务
传统的 Java Web 应用会在启动期间完成许多任务，例如预加载数据、预热缓存、建立连接池等。依次执行这些任务会很慢。但是，如果您希望它们并行执行，则应增加 CPU 核心数。
Knative 服务目前会发送实际用户请求以触发冷启动实例。其请求被分配到新启动实例的用户可能会遇到较长的延迟。Knative 服务目前没有“就绪性”检查，以避免向未就绪的应用发送请求。
使用连接池
如果您使用连接池，请注意，连接池可能会在后台逐出不需要的连接（请参阅避免后台任务）。如果应用的 QPS 较低，并且可以容忍高延迟，请考虑为每个请求打开和关闭连接。如果应用的 QPS 较高，则只要存在活跃请求，后台逐出就可能会继续执行。
在这两种情况下，应用的数据库访问都将在数据库允许的连接数上限方面遭遇瓶颈。计算每个 Knative 服务实例可建立的最大连接数，并配置 Knative 服务最大实例数，以使实例数上限与每个实例的连接数的乘积小于允许的连接数上限。
使用 Spring Boot
如果您使用 Spring Boot，则需要考虑以下优化
使用 Spring Boot 2.2 或更高版本
从 2.2 版开始，Spring Boot 已针对启动速度进行了大量优化。如果您使用的是低于 2.2 版的 Spring Boot，请考虑升级或手动应用各项优化。
使用延迟初始化
在 Spring Boot 2.2 及更高版本中，可以开启一个全局延迟初始化标志。这将提高启动速度，但代价是第一个请求的延迟时间可能变长，因为需要等待组件首次初始化。
您可以在 application.properties 中开启延迟初始化：
spring.main.lazy-initialization=true
或者，使用以下环境变量：
SPRING_MAIN_LAZY_INITIALIZATIION=true
但是，如果您使用的是 min-instances，由于 min-instance 启动时应已执行了初始化，因此延迟初始化没有什么用处。
避免类扫描
类扫描会在 Knative 服务过程中产生额外的磁盘读取，因为在 Knative 服务中，磁盘访问通常比常规机器慢。请确保进行有限的组件扫描或完全不进行组件扫描。考虑使用 Spring Context Indexer 来预生成索引。这是否会提高启动速度取决于您的应用。
例如，在 Maven pom.xml 中添加索引器依赖项（实际上是注解处理器）：
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context-indexer</artifactId>
<optional>true</optional>
</dependency>
使用不在生产中使用的 Spring Boot 开发者工具
如果您在开发过程中使用 Spring Boot 开发者工具，请确保未将其打包到生产容器映像中。如果您在没有 Spring Boot 构建插件（例如，使用 Shade 插件或使用 Jib 进行容器化）的情况下构建Spring Boot 应用，则可能会发生这种情况。
在这种情况下，请确保构建工具明确排除 Spring Boot 开发者工具。或者，明确关闭 Spring Boot 开发者工具。
后续步骤
如需查看更多提示，请参阅以下内容