Spring Boot 2.1和Java 11中的Bean生命周期

Question

我的项目正在从使用Java 8的Spring Boot 2.0.4迁移到使用Java 11的Spring Boot 2.1.0。当应用程序使用Spring Boot 2.0.4和Java 8构建并在Docker/Docker Compose中运行时，调用了@PostConstruct-带注释的方法，但在迁移到Spring Boot 2.1.0和Java 11之后，不再调用@PreDestroy-带注释的方法。

我尝试过从注释切换到实现initializebean和DisposableBean，如下所述，但是DisposableBean。不调用destroy方法。

我还尝试向javax.annotation版本1.3.2添加依赖项，结果相同。

如何复制：

使用生命周期bean创建一个最小的Spring应用程序：

import org.springframework.beans.factory.DisposableBean;
import org.springframework.beans.factory.InitializingBean;
import org.springframework.stereotype.Component;

@Component
public class Life implements InitializingBean, DisposableBean {
    @Override
    public void destroy() throws Exception {
        System.out.println("--- Life.shutdown");
    }
    @Override
    public void afterPropertiesSet() throws Exception {
        System.out.println("--- Life.startup");
    }
}

从目标子文件夹启动Spring应用程序：

cd target
java -jar demo-0.0.1-SNAPSHOT.jar

当应用程序使用Ctrl C停止时，DisposableBean。毁灭叫做毁灭。

返回到父文件夹：

cd ..

使用Maven启动Spring应用程序：

mvn spring-boot:run

当应用程序使用Ctrl C停止时，DisposableBean。毁灭叫做毁灭。

Dockerfile：

FROM openjdk:11.0.1-jre-slim
COPY target/*.jar app.jar
EXPOSE 8080
ENTRYPOINT java -jar /app.jar

生成、运行和停止Docker映像：

docker build -t demo .
docker run -p 8080:8080 demo
docker ps
docker stats 3ca5b804ab13
docker stop 3ca5b804ab13
docker logs 3ca5b804ab13

当应用程序使用docker stop停止时，DisposableBean。毁灭不叫毁灭。

docker撰写。yml：

demo:
  image: demo
  ports:
  - '8080:8080'

使用Docker Compose运行Docker image（模拟OpenShift）：

docker-compose up
docker-compose down
demo_demo_1 exited with code 137

当应用程序停止使用docker compose down时，DisposableBean。毁灭不叫毁灭。

我怀疑Docker在发出SIGKill之前正在尝试SIGTERM，因为在容器被杀死之前有10秒的延迟。

Answer 1

我想我找到了解决方案（在这篇博客文章中）：在Docker文件中使用exec表单而不是shell表单，这样Docker发出的SIGTERM会命中java进程，而不是bash进程（它不会将信号转发给任何子进程）。

• Shell表单（使用/bin/sh-cshell执行）：ENTRYPOINT java-jar/app。jar

Answer 2

在很多地方，设置可能会出错。首先，我建议确定java/spring部件是否存在一些问题，还是与docker/environment相关的问题。从这个问题来看，它听起来与java有关，但实际上我怀疑它不在java/spring中。

因此，mvn spring boot:run按预期工作，我看到您将spring boot应用程序打包为jar（app.jar），很可能带有spring boot插件。这也是一个可能出错的地方，因为spring boot使用一个特殊的类加载器在运行时加载内容。

因此，为了完全消除java/Spring部分，请导航到您的目标目录并运行java-jarapp.jar（当然，请确保java 11安装在您的本地机器上）。如果它不起作用-调查java /spring部分，否则继续使用docker部分。

应用程序很可能会按预期工作。

现在，关于docker的设置。在运行docker comush并看到它失败后，

可以使用以下命令：

docker ps -a // -a flag to see container ids of containers that were stopped for whatever reason as well.

现在找到退出的java进程的id并检查其日志：

docker logs <ID_OF_THE_EXTED_CONTAINER_GOES_HERE> 

现在，应用程序上下文很可能无法启动（可能是网络相关的问题或其他问题，在这里，如果看不到实际的日志，很难判断），因此出现了问题。

另一个可能的问题是应用程序“太重”（我的意思是它超过了docker容器上的一些配额）。

你可以运行docker统计