我正在进行与容器相关的冷启动问题实验，作为我的论文研究。我的测试应用程序是一个构建在openjdk镜像上的spring boot应用程序。我想要尝试解决冷启动问题的第一件事是:
有一个准备好的容器，容器里包含了openjdk和springboot应用程序使用的库。我启动我的另一个容器，使用已有容器的ipc和networknamespace，然后能够使用这个容器的openjdk和库来运行jar文件。
我不确定如何实现这个过程？我是否可以通过使用卷实现这个目标，还是应该寻找完全不同的方法？
另外，如果我想让x个容器运行，我会确保有x个预先存在的容器在运行。这是为了确保每个容器都有自己特定的库容器可供使用。这样做可以吗？
简而言之，任何能够通过使用通过ipc/net连接的第二个容器来加速spring boot应用程序的方法，都将对我的问题有所帮助。
Spring Boot是一个纯粹的“运行时”框架。
如果我理解你的问题正确，你描述的情况如下：
比如说你有一个带有JDK和一些jar包的容器A。但这本身并不意味着你有一个正在运行的进程。所以更像是一个准备重复使用的文件卷（或者在docker镜像方面的一个层）。
此外，你还有另一个容器B，其中包含一个应该以某种方式启动的Spring Boot应用程序（可能使用容器A中的OpenJDK或其专用JDK）。
现在你到底想要“加速”什么？镜像大小（更小的镜像意味着在CI/CD流水线中更快的部署）？Spring Boot应用程序启动时间（从生成JVM到Spring Boot应用程序启动运行的时间间隔）？或者你试图在运行时加载更少的类？
解决这些问题的技术是不同的。但总的来说，我认为你可能需要查看Graal VM集成，其中包括创建本机映像并加速启动时间的功能。这些东西相当新，我自己还没有尝试过。我相信这还在进行中，Spring将努力推动这一进展（这只是我的猜测，所以不要过分相信）。
无论如何，您可能会对阅读这篇文章感兴趣
然而，我怀疑它与您描述的研究有关。
更新1
根据您的评论-让我给出一些额外的信息，可能有所帮助。此更新包含来自“现实生活”工作经验的信息，我发布它是因为它可能有助于在您的论文中找到方向。
所以，我们首先有一个spring boot应用程序。
默认情况下，它是一个JAR文件，并且Pivotal建议提供WAR选项（正如他们的开发者代言人Josh Long所说：“制作JAR而不是WAR”）
这个spring boot应用程序通常包括一些Web服务器-传统的Spring Web MVC应用程序默认使用Tomcat，但您可以将其切换为Jetty或undertow。如果您正在运行“反应式应用程序”（Spring WebFlux自spring boot 2以来支持），则默认选择为Netty。
需要注意的是，并非所有使用Spring Boot驱动的应用程序都必须包含某种嵌入式Web服务器，但我将忽略这个微妙的点，因为您似乎针对Web服务器的情况（您提到了Tomcat，更快地处理请求等），因此我假设您是在关注此方面。
现在，让我们尝试分析启动Spring Boot应用程序JAR时发生的情况。
首先，JVM本身开始运行 - 进程启动，堆分配，内部类加载等等。这可能需要一些时间（大约需要1秒甚至更长时间，具体取决于服务器、参数、硬盘速度等）。 这个线程讨论了JVM是否真的启动缓慢，我可能无法为此添加更多内容。
好的，现在是时候加载Tomcat的内部类了。这又可以在现代服务器上花费几秒钟。Netty似乎更快，但您可以尝试下载Tomcat的独立发行版并在计算机上启动它，或者创建一个没有Spring Boot但有嵌入式Tomcat的示例应用程序来看看我在说什么。
到目前为止，我们的应用程序还没有出现问题。正如我在开始时所说，Spring Boot 是一个纯运行时框架。因此，必须加载 Spring/Spring Boot 本身的类，然后加载应用程序本身的类。如果应用程序使用某些库，它们也会被加载，有时甚至会在应用程序启动期间执行自定义代码：Hibernate 可以检查模式和/或扫描数据库模式定义，甚至更新底层模式，Flyway/Liquidbase 可以执行模式迁移等等，Swagger 可能会扫描控制器并生成文档等等。
libs文件夹中，它将仅由类加载器加载一次，这是每个“WAR”创建的类加载器的“父级”。这个类加载器层次结构非常重要，但我相信它超出了问题的范围。所以，如果加速应用程序启动是您的目标，我认为您需要采取不同的方法。以下是我认为如此的原因：
Docker: 容器是镜像的运行实例，可以将镜像看作文件系统（实际上不仅是这样，但我们正在讨论库）。在容器中，您有JDK（我猜您的镜像基于Tomcat）。Docker引擎具有非常良好设计的缓存系统，因此容器启动非常快，如果对容器没有进行更改，则Docker只需从缓存中检索一些信息。这些容器被隔离开来，出于好的原因（安全性，模块化以及关于库的隔离，使您可以在不同的容器中拥有更多版本的库）。卷并不是您想象的那样，它们不是设计用于共享库，它们允许您打破隔离以进行某些操作。例如，您可以为代码库创建一个卷，以便在编程阶段进行更改时无需为每个更改重新构建图像，但通常您在生产环境中看不到它们（也许是某些配置文件）。
Java/Spring：Spring是基于Java的框架，Java基于JDK，Java代码在虚拟机上运行。因此，要运行Java程序，您必须启动该虚拟机（没有其他方法），当然您无法缩短此启动时间。Java环境非常强大，但这就是为什么很多人更喜欢Node.js，特别是对于小型服务，Java代码的启动速度很慢（分钟级别相对于秒级别）。Spring如前所述基于Java，Servelets和Context。 Spring应用程序存在于该上下文中，因此要运行Spring应用程序，您必须初始化该上下文。
您正在运行一个容器，在其上运行一个虚拟机，然后初始化一个Spring上下文，并最终初始化应用程序的bean。出于依赖关系的原因，这些步骤是顺序执行的。您不能在初始化Docker、VM和Spring上下文后在其他地方运行应用程序，例如，如果您在Spring应用程序中添加了ChainFilter，则需要重新启动应用程序，因为您需要向系统添加Servlet。如果要加速启动过程，则需要更改Java VM或对Spring初始化进行一些更改。总之，您正在尝试以高层次而不是低层次来处理此问题。
回答你的第一个问题：
我不确定如何实现这个？我可以通过使用卷来实现吗，还是应该寻找完全不同的方法？
这必须与您基础设施的实际能力保持平衡。
一件事情是，如果您关心图像和层的大小，那么这很好，这绝对是Docker建议的良好实践，但所有这些都取决于您的需求。关于保持图像和层的小建议是为您要分发的图像。如果这是您自己的应用程序的自己的图像，则应根据您的需求采取行动。
以下是我的一点经验：在我曾工作的一家公司中，我们需要将数据库从生产环境同步回用户验收测试和开发环境。因此，在尝试了各种SQL文件的小改进（如禁用外键检查等）后，我想出了一个全新的方法：我创建了一个包含数据库的大型镜像，在每晚的构建中生成。这确实违反了Docker的所有最佳实践，但办公室的带宽允许容器在最坏的情况下在5分钟内启动，而之前需要20分钟。
因此，我的Docker SQL镜像的构建时间确实很长，但考虑到可用带宽，下载时间可接受，并且运行时间最大程度地缩短了。
这是利用一个事实的优势，即图像的构建只会发生一次，而从该图像派生的所有容器的启动时间将会发生。librarycontainer可供使用。这样做可以吗？not-library-container无法执行任何操作，因为它们与另一个容器的预先存在紧密耦合。library-container Dockerfile。FROM: openjdk:8-jdk-alpine
ARG JAR_FILE=target/*.jar
COPY ${JAR_FILE} app.jar
ENTRYPOINT ["java","-jar","/app.jar"]
来源: https://spring.io/guides/topicals/spring-boot-docker/#_a_basic_dockerfile
然后您可以通过以下方式构建它
docker build -t my/spring-boot .
然后，您可以在该图像的基础上构建另一个容器：
FROM: my/spring-boot
COPY some-specific-lib lib.jar
其次：Docker 中有一种很好的技术来处理库，称为多阶段构建，可以在您的情况下使用。
FROM openjdk:8-jdk-alpine as build
WORKDIR /workspace/app
COPY mvnw .
COPY .mvn .mvn
COPY pom.xml .
COPY src src
RUN ./mvnw install -DskipTests
RUN mkdir -p target/dependency && (cd target/dependency; jar -xf ../*.jar)
FROM openjdk:8-jdk-alpine
VOLUME /tmp
ARG DEPENDENCY=/workspace/app/target/dependency
COPY --from=build ${DEPENDENCY}/BOOT-INF/lib /app/lib
COPY --from=build ${DEPENDENCY}/META-INF /app/META-INF
COPY --from=build ${DEPENDENCY}/BOOT-INF/classes /app
ENTRYPOINT ["java","-cp","app:app/lib/*","hello.Application"]
来源：https://spring.io/guides/topicals/spring-boot-docker/#_multi_stage_build
正如在这个多阶段构建的来源中所述，Spring官网的指南中甚至提到了这种技术。
entrypoint安装了第三方库，那么答案肯定是肯定的；如果是其他原因，那么你就必须理解它是什么，并且是否可以构建到你的容器中。最终，在纯Docker的角度来看，这就是你应该问自己的问题：“我有什么，我需要什么，我的所谓启动时间中的一些时间可以转移到构建时间吗？” - β.εηοιτ.βε# Dockerfile
FROM oracle/graalvm-ce AS builder
LABEL maintainer="Igwe Kalu <igwe.kalu@live.com>"
COPY HelloWorld.java /app/HelloWorld.java
RUN \
set -euxo pipefail \
&& gu install native-image \
&& cd /app \
&& javac HelloWorld.java \
&& native-image HelloWorld
FROM debian:10.4-slim
COPY --from=builder /app/helloworld /app/helloworld
CMD [ "/app/helloworld" ]
# .dockerignore
**/*
!HelloWorld.java
// HelloWorld.java
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello, Native Java World!");
}
}
构建镜像并运行容器：
# Building...
docker build -t graalvm-demo-debian-v0 .
# Running...
docker run graalvm-demo-debian-v0:latest
## Prints
## Hello, Native Java World!
Spring Tips: The GraalVM Native Image Builder Feature 是一篇演示如何使用GraalVM构建Spring Boot应用程序的文章。
容器意味着隔离。这就回答了你如何在容器之间使用共享库的问题。但是你可以通过阶段创建你的Docker镜像，比如一个库的镜像、一个应用程序的镜像、一个第三方应用程序的镜像，在运行时只需调用创建容器的组合即可。 - Dupinder Singh