ShutdownHook妙用

FunTester

发布于 2023-09-11 11:27:14

1340

发布于 2023-09-11 11:27:14

文章被收录于专栏：FunTester

上期文章分享了ShutdownHook的API和基本使用，但是少了一些实际工作中的案例，总感觉没啥大用一样。

最近总结工作中可以用到ShutdownHook来解决一些实际问题的例子，分享给大家。

任务统计

FunTester测试框架定义了好几个自定义的异步关键字，例如fun、funny、funner等。一旦使用到异步，肯定会用到线程池。但是「Java」线程池销毁需要手动操作，之前的视线中是放在「daemon」线程中实现。如果我想在每次JVM关闭之前都统计一下线程池执行任务总数，就不能写在daemon线程中了，原因有二：

daemon线程可能出现异常，导致退出。
用户可能会主动停止程序，例如C

虽然可以通过自定义daemon线程解决这个问题。如果你想使用一种优雅的方法完成这个任务的话，那么ShutdownHook绝对是不二选择。

static {  
    addShutdownHook {  
        if (asyncPool != null) {  
            print "finished: " + getFunPool().getCompletedTaskCount() + " task"  
        }  
        RuntimeMXBean runtimeMXBean = ManagementFactory.getRuntimeMXBean()  
        print(" uptime:" + runtimeMXBean.getUptime() + " s")  
    }  
}

通过静态代码块把两个ShutdownHook注册到JVM中，这一点也是从Web3j异步线程池源码中学到的。当然这只是个初级版本，这里抛砖引玉。

这里本地的动态QPS模型经常会用到java.util.Scanner来接收控制台输入信息，也需要进行资源回收。

static {  
    Runtime.getRuntime().addShutdownHook(new Thread(() -> closeScanner()));  
}

释放连接

ShutdownHook最重要的一个功能就是释放资源，通常如果是非服务形式启动一个JVM进程的话，只有确保JVM进程能够正常退出的话，通常不用担心资源泄露或者无法回收的问题。如果对于Java服务的话，通常使用池化框架来管理连接资源。对于测试工作来讲，我觉得足够了，只有很少细微的差别。

所以我对com.funtester.httpclient.FunHttp做了一点改造，这次用的Java的API：

    /**
     * 结束测试，关闭连接池
     */
    static {
        Runtime.getRuntime().addShutdownHook(new Thread(() -> {
            try {
                ClientManage.httpsClient.close();
            } catch (IOException e) {
                e.printStackTrace();
            }
            try {
                ClientManage.httpAsyncClient.close();
            } catch (IOException e) {
                e.printStackTrace();
            }
        }));

    }

这里查了一些客户端主动断开连接和客户端JVM直接关闭对服务端的影响，可供参考：

「客户端主动发送断开连接：」 当客户端在与服务器建立的 HTTPS 连接上主动发送断开连接请求（通过关闭连接），服务器会接收到这个请求，并根据 HTTP 协议的规范进行处理。服务器会知道连接被关闭，这可以触发服务器端的一些清理操作，例如释放连接资源，清理会话状态等。这是一个正常的连接关闭过程，服务器端会收到关闭连接的通知。
「客户端直接关闭：」 当客户端断开与服务端连接（例如断网），服务器无法立即感知到这个变化。这是因为客户端和服务器之间的连接是通过网络进行的，服务器没有直接的方式知道客户端是否断开了网络连接。在这种情况下，服务器会等待一段时间，直到发现客户端不再发送请求或响应。服务器可能会将这个连接保持一段时间，然后最终超时并关闭连接。

总之，客户端主动发送断开连接是一个明确的行为，服务器能够立即响应。而客户端断网可能会导致连接在服务器端保持一段时间，直到服务器超时或检测到连接不再活动。服务器通常会实现一些超时机制来管理连接，以防止持久的无效连接占用资源。

所以如果考虑这些细微的差别，还是选用主动断开回收这些资源。

PS：到这里，当我们需要添加超过1个ShutdownHook的时候，就可以非常明显地感受到daemon线程实现方案的差异，因为ShutdownHook可以到处写，多点开花。

应对JVM异常退出

如果你在使用docker和k8s的话，压测很容易导致JVM进程被迫退出。这个时候容器可能还在，只是JVM进程退出了，如果我们在基础依赖中，添加上下面这段代码，就可以发送消息。

    static {
        addShutdownHook {
            send("我挂了,顺便采集了快照!")
            snapshot()
        }
    }

状态记录

性能测试中，造数据的工作同行是繁琐且量大，一般都会使用脚本或者平台实现。但在实际使用当中总会遇到各种各样的异常，导致部分已经创建好的数据丢失，或者需要重新查库才能恢复。

下面是一个例子，场景：需要创建100w个新用户（假设用户属性均在已经封装好的方法中完成设置）。

import com.funtester.frame.Save
import com.funtester.frame.SourceCode
import com.funtester.utils.RWUtil

class HookTest extends SourceCode {

    static Vector<Integer> ids = RWUtil.readByNumLine(getLongFile("ids"))

    static void main(String[] args) {
        100_0000.times {
            if (ids.size() > 100_0000) fail()
            fun {
                def id = create()
                if (id > 0) {
                    ids << id
                }
            }
        }
    }

    static {
        addShutdownHook {
            Save.saveIntegerList(ids, getLongFile("ids"))
        }
    }

    static int create() {
        getRandomInt(Integer.MAX_VALUE)
    }
}

这里循环100w次，使用默认的线程池并发创建用户，如果用户的ID是大于0，认为正常用户，添加到线程安全的队列中。

一旦遇到异常，ShutdownHook中的方法会把已经创建好的用户ID存在文件中。每次执行，已创建好的用户ID集合会从文件中进行初始化。

多次执行，直到fail()抛异常，最后一次ids文件就是我们需要的创建用户的ID集合。