Spring-boot+Dubbo应用启停源码分析-低调大师

Spring-boot+Dubbo应用启停源码分析

2018-05-28 571

背景介绍

Dubbo Spring Boot 工程致力于简化 Dubbo RPC 框架在Spring Boot应用场景的开发。同时也整合了 Spring Boot 特性：

自动装配 (比如：注解驱动, 自动装配等).
Production-Ready (比如：安全, 健康检查, 外部化配置等).

DubboConsumer启动分析

你有没有想过一个问题？incubator-dubbo-spring-boot-project中的DubboConsumerDemo应用就一行代码，main方法执行完之后，为什么不会直接退出呢？

@SpringBootApplication(scanBasePackages = "com.alibaba.boot.dubbo.demo.consumer.controller")
public class DubboConsumerDemo {

    public static void main(String[] args) {
        SpringApplication.run(DubboConsumerDemo.class,args);
    }

}

其实要回答这样一个问题，我们首先需要把这个问题进行一个抽象，即一个JVM进程，在什么情况下会退出？

以Java 8为例，通过查阅JVM语言规范[1]，在12.8章节中有清晰的描述：

A program terminates all its activity and exits when one of two things happens:

All the threads that are not daemon threads terminate.
Some thread invokes the exit method of class Runtime or class System, and the exit operation is not forbidden by the security manager.

也就是说，导致JVM的退出只有2种情况：

所有的非daemon进程完全终止
某个线程调用了System.exit()或Runtime.exit()

因此针对上面的情况，我们判断，一定是有某个非daemon线程没有退出导致。我们知道，通过jstack可以看到所有的线程信息，包括他们是否是daemon线程，可以通过jstack找出那些是非deamon的线程。

  jstack 57785 | grep tid | grep -v "daemon"
"container-0" #37 prio=5 os_prio=31 tid=0x00007fbe312f5800 nid=0x7103 waiting on condition  [0x0000700010144000]
"container-1" #49 prio=5 os_prio=31 tid=0x00007fbe3117f800 nid=0x7b03 waiting on condition  [0x0000700010859000]
"DestroyJavaVM" #83 prio=5 os_prio=31 tid=0x00007fbe30011000 nid=0x2703 waiting on condition  [0x0000000000000000]
"VM Thread" os_prio=31 tid=0x00007fbe3005e800 nid=0x3703 runnable
"GC Thread#0" os_prio=31 tid=0x00007fbe30013800 nid=0x5403 runnable
"GC Thread#1" os_prio=31 tid=0x00007fbe30021000 nid=0x5303 runnable
"GC Thread#2" os_prio=31 tid=0x00007fbe30021800 nid=0x2d03 runnable
"GC Thread#3" os_prio=31 tid=0x00007fbe30022000 nid=0x2f03 runnable
"G1 Main Marker" os_prio=31 tid=0x00007fbe30040800 nid=0x5203 runnable
"G1 Conc#0" os_prio=31 tid=0x00007fbe30041000 nid=0x4f03 runnable
"G1 Refine#0" os_prio=31 tid=0x00007fbe31044800 nid=0x4e03 runnable
"G1 Refine#1" os_prio=31 tid=0x00007fbe31045800 nid=0x4d03 runnable
"G1 Refine#2" os_prio=31 tid=0x00007fbe31046000 nid=0x4c03 runnable
"G1 Refine#3" os_prio=31 tid=0x00007fbe31047000 nid=0x4b03 runnable
"G1 Young RemSet Sampling" os_prio=31 tid=0x00007fbe31047800 nid=0x3603 runnable
"VM Periodic Task Thread" os_prio=31 tid=0x00007fbe31129000 nid=0x6703 waiting on condition

此处通过grep tid 找出所有的线程摘要，通过grep -v找出不包含daemon关键字的行

通过上面的结果，我们发现了一些信息：

有两个线程container-0, container-1非常可疑，他们是非daemon线程，处于wait状态
有一些GC相关的线程，和VM打头的线程，也是非daemon线程，但他们很有可能是JVM自己的线程，在此暂时忽略。

综上，我们可以推断，很可能是因为container-0和container-1导致JVM没有退出。现在我们通过源码，搜索一下到底是谁创建的这两个线程。

通过对spring-boot的源码分析，我们在org.springframework.boot.context.embedded.tomcat.TomcatEmbeddedServletContainer的startDaemonAwaitThread找到了如下代码

    private void startDaemonAwaitThread() {
        Thread awaitThread = new Thread("container-" + (containerCounter.get())) {

            @Override
            public void run() {
                TomcatEmbeddedServletContainer.this.tomcat.getServer().await();
            }

        };
        awaitThread.setContextClassLoader(getClass().getClassLoader());
        awaitThread.setDaemon(false);
        awaitThread.start();
    }

在这个方法加个断点，看下调用堆栈：

initialize:115, TomcatEmbeddedServletContainer (org.springframework.boot.context.embedded.tomcat)
<init>:84, TomcatEmbeddedServletContainer (org.springframework.boot.context.embedded.tomcat)
getTomcatEmbeddedServletContainer:554, TomcatEmbeddedServletContainerFactory (org.springframework.boot.context.embedded.tomcat)
getEmbeddedServletContainer:179, TomcatEmbeddedServletContainerFactory (org.springframework.boot.context.embedded.tomcat)
createEmbeddedServletContainer:164, EmbeddedWebApplicationContext (org.springframework.boot.context.embedded)
onRefresh:134, EmbeddedWebApplicationContext (org.springframework.boot.context.embedded)
refresh:537, AbstractApplicationContext (org.springframework.context.support)
refresh:122, EmbeddedWebApplicationContext (org.springframework.boot.context.embedded)
refresh:693, SpringApplication (org.springframework.boot)
refreshContext:360, SpringApplication (org.springframework.boot)
run:303, SpringApplication (org.springframework.boot)
run:1118, SpringApplication (org.springframework.boot)
run:1107, SpringApplication (org.springframework.boot)
main:35, DubboConsumerDemo (com.alibaba.boot.dubbo.demo.consumer.bootstrap)

可以看到，spring-boot应用在启动的过程中，由于默认启动了Tomcat暴露HTTP服务，所以执行到了上述方法，而Tomcat启动的所有的线程，默认都是daemon线程，例如监听请求的Acceptor，工作线程池等等，如果这里不加控制的话，启动完成之后JVM也会退出。因此需要显示的启动一个线程，在某个条件下进行持续等待，从而避免线程退出。

下面我们在深挖一下，在Tomcat的this.tomcat.getServer().await()这个方法中，线程是如何实现不退出的。这里为了阅读方便，去掉了不相关的代码。

public void await() {
        // ...
        if( port==-1 ) {
            try {
                awaitThread = Thread.currentThread();
                while(!stopAwait) {
                    try {
                        Thread.sleep( 10000 );
                    } catch( InterruptedException ex ) {
                        // continue and check the flag
                    }
                }
            } finally {
                awaitThread = null;
            }
            return;
        }
        // ...
    }

在await方法中，实际上当前线程在一个while循环中每10秒检查一次 stopAwait这个变量，它是一个volatile类型变量，用于确保被另一个线程修改后，当前线程能够立即看到这个变化。如果没有变化，就会一直处于while循环中。这就是该线程不退出的原因，也就是整个spring-boot应用不退出的原因。

因为Springboot应用同时启动了8080和8081(management port)两个端口，实际是启动了两个Tomcat，因此会有两个线程container-0和container-1。

接下来，我们再看看，这个Spring-boot应用又是如何退出的呢？

DubboConsumer退出分析

在前面的描述中提到，有一个线程持续的在检查stopAwait这个变量，那么我们自然想到，在Stop的时候，应该会有一个线程去修改stopAwait，打破这个while循环，那又是谁在修改这个变量呢？

通过对源码分析，可以看到只有一个方法修改了stopAwait,即org.apache.catalina.core.StandardServer#stopAwait，我们在此处加个断点，看看是谁在调用。

注意，当我们在Intellij IDEA的Debug模式，加上一个断点后，需要在命令行下使用kill -s INT $PID或者kill -s TERM $PID才能触发断点，点击IDE上的Stop按钮，不会触发断点。这是IDEA的bug

可以看到有一个名为Thread-3的线程调用了该方法：

stopAwait:390, StandardServer (org.apache.catalina.core)
stopInternal:819, StandardServer (org.apache.catalina.core)
stop:226, LifecycleBase (org.apache.catalina.util)
stop:377, Tomcat (org.apache.catalina.startup)
stopTomcat:241, TomcatEmbeddedServletContainer (org.springframework.boot.context.embedded.tomcat)
stop:295, TomcatEmbeddedServletContainer (org.springframework.boot.context.embedded.tomcat)
stopAndReleaseEmbeddedServletContainer:306, EmbeddedWebApplicationContext (org.springframework.boot.context.embedded)
onClose:155, EmbeddedWebApplicationContext (org.springframework.boot.context.embedded)
doClose:1014, AbstractApplicationContext (org.springframework.context.support)
run:929, AbstractApplicationContext$2 (org.springframework.context.support)

通过源码分析，原来是通过Spring注册的ShutdownHook来执行的

    @Override
    public void registerShutdownHook() {
        if (this.shutdownHook == null) {
            // No shutdown hook registered yet.
            this.shutdownHook = new Thread() {
                @Override
                public void run() {
                    synchronized (startupShutdownMonitor) {
                        doClose();
                    }
                }
            };
            Runtime.getRuntime().addShutdownHook(this.shutdownHook);
        }
    }

通过查阅Java的API文档[2], 我们可以知道ShutdownHook将在下面两种情况下执行

The Java virtual machine shuts down in response to two kinds of events:

The program exits normally, when the last non-daemon thread exits or when the exit (equivalently, System.exit) method is invoked, or

The virtual machine is terminated in response to a user interrupt, such as typing ^C, or a system-wide event, such as user logoff or system shutdown.

调用了System.exit()方法
响应外部的信号，例如Ctrl+C（其实发送的是SIGINT信号），或者是SIGTERM信号（默认kill $PID发送的是SIGTERM信号）

因此，正常的应用在停止过程中(kill -9 $PID除外)，都会执行上述ShutdownHook，它的作用不仅仅是关闭tomcat，还有进行其他的清理工作，在此不再赘述。

总结

在DubboConsumer启动的过程中，通过启动一个独立的非daemon线程循环检查变量的状态，确保进程不退出
在DubboConsumer停止的过程中，通过执行spring容器的shutdownhook，修改了变量的状态，使得程序正常退出

问题

在DubboProvider的例子中，我们看到Provider并没有启动Tomcat提供HTTP服务，那又是如何实现不退出的呢？我们将在下一篇文章中回答这个问题。

彩蛋

在 Intellij IDEA中运行了如下的单元测试，创建一个线程执行睡眠1000秒的操作，我们惊奇的发现，代码并没有线程执行完就退出了，这又是为什么呢？（被创建的线程是非daemon线程）

    @Test
    public void test() {
        new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    Thread.sleep(1000000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }).start();
    }

[1] https://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html#jls-12.8

[2] https://docs.oracle.com/javase/8/docs/api/java/lang/Runtime.html#addShutdownHook

微信关注我们

原文链接：https://yq.aliyun.com/articles/598068

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

IT技术人员转行大数据应该考虑哪些问题

大数据人才需求迫切，高薪资、高福利，因此转行的大数据的人也很多，那么对于一些普通技术开发人员，在进行转行大数据开发时有哪些必要的考虑因素呢？关于从事一个行业的要求，最简单的方式莫过于从求职网站上查看信息，下面就是针对于大数据行业的一些职业要求，而这也是转行大数据人必须要考虑的。分享之前我还是要推荐下我自己创建的大数据学习交流Qun531629188无论是大牛还是想转行想学习的大学生小编我都挺欢迎，今天的已经资讯上传到群文件，不定期分享干货，包括我自己整理的一份最新的适合2018年学习的大数据教程，欢迎初学和进阶中的小伙伴。 1、丰富的数据开发经验，对数据处理、数据建模、数据分析等有深刻认识和实战经验。 2、熟悉SQL，有一定的SQL性能优化经验。 3、熟练掌握Java语言，MapReduce编程，脚本语言Shell/Python/Perl之一。 4、业务理解力强，对数据、新技术敏感，对云计算、大数据技术充满热情。 5、深入理解Map-Reduce模型，对Hadoop、Spark、Storm等大规模数据存储与运算平台有实践经验。这五点因素并代表全部，只是为大家罗列出一些基础的技能，...

2018-05-29

538

获取类名的方法 Java 中获取类名的方式主要有以下三种。 getName() 返回的是虚拟机里面的class的类名表现形式。 getCanonicalName() 返回的是更容易理解的类名表示。 getSimpleName() 返回的是类的简称。都有什么区别？通过一个实例来看下它们主要的区别。 public class TestClass { public static void main(String[] args) { // 外部普通类 System.out.println("方法名类名"); System.out.println("getName " + TestClass.class.getName()); System.out.println("getCanonicalName " + TestClass.class.getCanonicalName()); System.out.println("getSimpleName " + TestClass.class.getSimpleName()); System.out.println(); // 内部类 Syste...

2018-05-29

584

资源下载

更多资源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。