自动关闭的Java代理（Jedis资源）

Question

我试图找出是否有可能创建Java动态代理来自动关闭自动关闭资源，而不必记住用try资源块嵌入这些资源。

例如，我有一个JedisPool，它有一个getResource方法，可以这样使用：

try(Jedis jedis = jedisPool.getResource() {
   // use jedis client
}

现在我做了这样的事情：

class JedisProxy implements InvocationHandler {

    private final JedisPool pool;

    public JedisProxy(JedisPool pool) {
        this.pool = pool;
    }

    public static JedisCommands newInstance(Pool<Jedis> pool) {
        return (JedisCommands) java.lang.reflect.Proxy.newProxyInstance(
            JedisCommands.class.getClassLoader(),
            new Class[] { JedisCommands.class },
            new JedisProxy(pool));
    }

    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        try (Jedis client = pool.getResource()) {
            return method.invoke(client, args);
        } catch (InvocationTargetException e) {
            throw e.getTargetException();
        } catch (Exception e) {
            throw e;
        }
    }
}

现在，每次我在Jedis（JedisCommands）上调用method时，这个方法都会被传递给代理，代理从池中获取一个新的客户端，执行这个方法并将这个资源返回到池中。

它工作得很好，但当我想在客户机上执行多个方法时，每个方法的资源都会从池中取出并再次返回（这可能很耗时）。你知道如何改进吗？

Answer 1

我不认为这是朝着正确的方向前进。毕竟，开发人员应该习惯于正确处理资源，并且IDE/编译器能够在未使用try（...）{}处理自动关闭资源时发出警告...

然而，创建一个代理来装饰所有调用，并添加一种方法来装饰一批多个操作作为一个整体，这是一项一般性的任务，因此，它有一个通用的解决方案：

class JedisProxy implements InvocationHandler {

    private final JedisPool pool;

    public JedisProxy(JedisPool pool) {
        this.pool = pool;
    }

    public static JedisCommands newInstance(Pool<Jedis> pool) {
        return (JedisCommands) java.lang.reflect.Proxy.newProxyInstance(
            JedisCommands.class.getClassLoader(),
            new Class[] { JedisCommands.class },
            new JedisProxy(pool));
    }

    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        try (Jedis client = pool.getResource()) {
            return method.invoke(client, args);
        } catch (InvocationTargetException e) {
            throw e.getTargetException();
        }
    }
    public static void executeBatch(JedisCommands c, Consumer<JedisCommands> action) {
        InvocationHandler ih = Proxy.getInvocationHandler(c);
        if(!(ih instanceof JedisProxy))
            throw new IllegalArgumentException();
        try(JedisCommands actual=((JedisProxy)ih).pool.getResource()) {
            action.accept(actual);
        }
    }
    public static <R> R executeBatch(JedisCommands c, Function<JedisCommands,R> action){
        InvocationHandler ih = Proxy.getInvocationHandler(c);
        if(!(ih instanceof JedisProxy))
            throw new IllegalArgumentException();
        try(JedisCommands actual=((JedisProxy)ih).pool.getResource()) {
            return action.apply(actual);
        }
    }
}

请注意，池的类型转换

现在你可以像这样使用它了

JedisCommands c=JedisProxy.newInstance(pool);

c.someAction();// aquire-someaction-close

JedisProxy.executeBatch(c, jedi-> {
    jedi.someAction();
    jedi.anotherAction();
}); // aquire-someaction-anotherAction-close

ResultType foo = JedisProxy.executeBatch(c, jedi-> {
    jedi.someAction();
    return jedi.someActionReturningValue(…);
}); // aquire-someaction-someActionReturningValue-close-return the value

批处理执行要求实例是代理，否则会引发异常，因为很明显，该方法无法保证具有未知生命周期的未知实例的特定行为。

此外，开发人员现在必须了解代理和批处理执行功能，就像不使用代理时必须了解资源和try（…）{}语句一样。另一方面，如果没有，在不使用批处理方法的情况下调用代理上的多个方法时，它们会失去性能，而在不使用try（…）{}在实际的非代理资源上调用多个方法时，它们会让资源泄漏…

Answer 2

最终，您将拥有自己的“事务管理器”，在该管理器中，您通常会立即将对象返回到池中，但如果您启动了“事务”，则在“提交”该“事务”之前，对象不会返回到池中。

突然之间，由于使用了手工构建的自定义机制，使用try-with-Resources的问题变成了实际问题。

与资源专家一起使用try：

• 语言内置功能
• 允许你附加一个捕获块，资源仍然被释放
• 简单、一致的语法，这样即使开发人员不熟悉它，他也会看到所有被它包围的Jedis代码，并（希望）认为“所以这一定是使用这个的正确方式”

欺骗：

• 你需要记住使用它

你的建议优点（如果我忘记了什么，你可以告诉我）：

• 即使开发人员没有关闭资源，也会自动关闭，以防止资源泄漏

欺骗：

• 额外的代码总是意味着额外的地方发现错误
• 如果你不创建一个事务机制，你可能会遭受性能打击（我不熟悉[jr]edis或你的项目，所以我不能说这是否真的是一个问题）
• 如果你真的创建了它，你会有更多的额外的代码，这很容易出错
• 语法不再简单，对任何来项目的人来说都会感到困惑
• 异常处理变得更加复杂
• 您将通过反思进行所有代理调用（一个小问题，但嘿，这是我的列表；）
• 可能更多，取决于最终的实现方式

如果你认为我没有提出有效的观点，请告诉我。否则，我的断言将仍然是“你有一个寻找问题的‘解决方案’”。