本文探讨了如何利用groovy闭包（closure）将具有相似逻辑但条件不同的重复轮询方法合并为一个通用、灵活且可维护的方法。通过抽象出变化的条件判断逻辑，我们能够显著减少代码冗余，提高代码复用性，并优化性能，避免在频繁调用中创建不必要的对象。
在软件开发中，我们经常会遇到需要等待某个外部条件满足才能继续执行的场景。例如，等待网络连接成功，或等待某个操作返回预期的结果。当这些等待逻辑在不同场景下仅有条件判断部分不同时，很容易导致代码重复。
考虑以下两个Groovy方法示例：
def someCondition = false
def method1() {
while(!someCondition) {
def connectionStatus = getConnectionStatus() // return 200, 404, etc.
if (connectionStatus == 200) {
someCondition = true
} else {
println "repeat until connection is 200"
sleep 15
}
}
}
def method2(){
while(!someCondition) {
def result = getResult() // A, B, C, etc.
if (result in ["A", "B", "C"]) {
someCondition = true
} else {
println "waiting until result is either A, B, or C"
sleep 15
result = getResult() // call again to check if result changed
}
}
}这两个方法都包含一个 while 循环，在循环内部执行某个操作，然后根据不同的条件判断是否满足退出循环。除了 if 语句中的条件不同外，其余的轮询、等待（sleep）和日志输出逻辑几乎完全一致。这种代码模式是典型的重复代码，不利于维护和扩展。
利用闭包抽象轮询逻辑
Groovy的闭包提供了一种优雅的方式来解决这类问题。我们可以创建一个通用的轮询方法，将变化的条件判断逻辑作为闭包参数传递进去。
首先，定义一个名为 waitUntil 的通用方法。这个方法将负责处理轮询的通用框架，包括重试次数、休眠时间以及执行条件判断。
/** * 持续等待直到某个条件满足。 * * @param sleep 每次重试之间的休眠时间（毫秒）。 * @param maxRetries 最大重试次数。 * @param test 一个返回布尔值的闭包，当条件满足时返回 true。 */ def waitUntil(int sleep = 1, int maxRetries = 10, Closuretest) { int retries = 0 while (retries++ < maxRetries && !test()) { println "Failed at attempt $retries/$maxRetries, sleeping for $sleep ms before retrying" Thread.sleep(sleep) } // 可选：如果需要知道是否成功，可以返回 test() 的最终结果 // return test() }
在这个 waitUntil 方法中：
- sleep 参数定义了每次重试之间的等待时间，默认为1毫秒。
- maxRetries 参数定义了最大重试次数，默认为10次。
- test 参数是一个 Closure
类型的闭包，它封装了实际的条件判断逻辑。当这个闭包执行返回 true 时，表示条件已满足，轮询结束。
使用示例
现在，我们可以使用这个通用的 waitUntil 方法来替代之前的 method1 和 method2。
示例1：等待 getResult() 返回特定值
// 假设 getResult() 方法存在
def getResult() {
// 模拟异步操作，可能返回不同的值
def values = ["X", "Y", "A", "B", "Z"]
values[new Random().nextInt(values.size())]
}
// 替换 method2 的逻辑
println "Waiting for result A, B, or C..."
waitUntil {
getResult() in ["A", "B", "C"]
}
println "Condition met or max retries reached."示例2：自定义休眠时间
// 替换 method1 的逻辑，假设 getConnectionStatus() 方法存在
def getConnectionStatus() {
// 模拟网络请求
def statuses = [404, 500, 200, 403]
statuses[new Random().nextInt(statuses.size())]
}
println "Waiting for connection status 200 with longer sleep..."
waitUntil(100) { // 每次重试休眠100毫秒
getConnectionStatus() == 200
}
println "Condition met or max retries reached."示例3：自定义休眠时间和最大重试次数
println "Waiting with custom sleep and retries..."
waitUntil(200, 5) { // 每次休眠200毫秒，最多重试5次
// 某个耗时操作或外部条件
new Random().nextBoolean() // 模拟随机成功
}
println "Condition met or max retries reached."优化：避免重复创建对象
在上述示例中，如果闭包内部需要判断一个值是否在一个集合中（例如 getResult() in ["A", "B", "C"]），那么每次闭包执行时都会创建一个新的列表 ["A", "B", "C"]。对于高频或长时间运行的轮询任务，这可能会导致大量的临时对象被创建，增加垃圾回收（GC）的负担。
为了优化这一点，我们可以将这些不变的参数作为 waitUntil 方法的参数传入，然后通过闭包的隐式参数 it 或显式参数传递给闭包。
/** * 持续等待直到某个条件满足，并支持传入额外参数到闭包。 * * @param closureArgs 传递给闭包的额外参数。 * @param sleep 每次重试之间的休眠时间（毫秒）。 * @param maxRetries 最大重试次数。 * @param test 一个返回布尔值的闭包，当条件满足时返回 true。 */ def waitUntil(Object closureArgs, int sleep = 1, int maxRetries = 10, Closuretest) { int retries = 0 while (retries++ < maxRetries && !test(closureArgs)) { // 将 closureArgs 传递给闭包 println "Failed at attempt $retries/$maxRetries, sleeping for $sleep ms before retrying" Thread.sleep(sleep) } }
现在，我们可以这样调用：
// 替换 method2 的优化版本
println "Waiting for result A, B, or C (optimized)..."
def expectedResults = ["A", "B", "C"] // 列表只创建一次
waitUntil(expectedResults) { it -> // 闭包接收一个参数 'it'，即 expectedResults
getResult() in it
}
println "Condition met or max retries reached."通过这种方式，expectedResults 列表只会在 waitUntil 方法调用时创建一次，而不是在每次闭包执行时都创建，从而减少了不必要的对象创建。
总结与注意事项
通过利用Groovy闭包，我们成功地将重复的轮询逻辑抽象成一个通用方法，显著提高了代码的复用性和可维护性。
这种模式的优点包括：
- 减少代码重复： 将通用的轮询框架与变化的条件判断分离。
- 提高可读性： 业务逻辑（条件判断）清晰地封装在闭包中。
- 增强灵活性： 可以轻松地调整重试策略（休眠时间、最大重试次数）。
- 优化性能： 通过参数传递避免在循环中重复创建对象。
注意事项：
- 闭包的副作用： 确保闭包内的操作不会产生意外的副作用，或者副作用是可控且期望的。
- 异常处理： 在实际应用中，getConnectionStatus() 或 getResult() 这类方法可能会抛出异常。在闭包内部或 waitUntil 方法中增加适当的异常处理机制是必要的。
- 无限循环风险： 如果 maxRetries 设置过大或条件永远无法满足，可能会导致长时间阻塞。合理设置 maxRetries 和 sleep 参数至关重要。
- 线程安全： 如果被轮询的条件涉及共享状态，需要考虑线程安全问题。
通过这种模式，开发者可以编写出更简洁、更健壮、更易于维护的Groovy代码，有效管理应用程序中的各种等待和轮询场景。
