В Java, как проверить, что AutoCloseable.close() был вызван?

Если вас интересует согласованность в тестах, просто добавьте в тестовый класс метод destroy(), отмеченный аннотацией @AfterClass, и закройте в нем все ранее выделенные ресурсы.

Если вас интересует подход, позволяющий защитить ресурс от того, чтобы он не был закрыт, вы можете предоставить способ, который не предоставляет ресурс пользователю явно. Например, ваш код может контролировать жизненный цикл ресурса и принимать от пользователя только Consumer<T>.

Если вы не можете этого сделать, но все же хотите быть уверены, что ресурс будет закрыт, даже если пользователь использует его неправильно, вам придется сделать несколько хитрых вещей. Вы можете разделить свой ресурс на sharedPtr и сам resource. Затем откройте sharedPtr пользователю и поместите его во внутреннее хранилище, завернутое в WeakReference. В результате вы сможете поймать момент, когда GC удалит sharedPtr и вызовет close() на resource. Имейте в виду, что resource не должен открываться пользователю. Я подготовил пример, он не очень точен, но надеюсь, что он показывает идею:

public interface Resource extends AutoCloseable {

    public int jniCall();
}

class InternalResource implements Resource {

    public InternalResource() {
        // Allocate resources here.
        System.out.println("Resources were allocated");
    }

    @Override public int jniCall() {
        return 42;
    }

    @Override public void close() {
        // Dispose resources here.
        System.out.println("Resources were disposed");
    }
}

class SharedPtr implements Resource {

    private final Resource delegate;

    public SharedPtr(Resource delegate) {
        this.delegate = delegate;
    }

    @Override public int jniCall() {
        return delegate.jniCall();
    }

    @Override public void close() throws Exception {
        delegate.close();
    }
}

public class ResourceFactory {

    public static Resource getResource() {
        InternalResource resource = new InternalResource();
        SharedPtr sharedPtr = new SharedPtr(resource);

        Thread watcher = getWatcherThread(new WeakReference<>(sharedPtr), resource);
        watcher.setDaemon(true);
        watcher.start();

        Runtime.getRuntime().addShutdownHook(new Thread(resource::close));

        return sharedPtr;
    }

    private static Thread getWatcherThread(WeakReference<SharedPtr> ref, InternalResource resource) {
        return new Thread(() -> {
            while (!Thread.currentThread().isInterrupted() && ref.get() != null)
                LockSupport.parkNanos(1_000_000);

            resource.close();
        });
    }
}

Если бы я был вами, я бы сделал следующее:

• Напишите статическую оболочку вокруг ваших вызовов, которая возвращает «тяжелые» объекты.
• Создайте коллекцию PhantomReferences для хранения всех ваших тяжелых объектов в целях очистки.
• Создайте коллекцию Слабые ссылки для хранения всех ваших тяжелых объектов, чтобы проверить, являются ли они GC'd или нет (имеют ссылку от вызывающего или нет)
• При разрыве я бы проверил оболочку, чтобы увидеть, какие ресурсы были GC'd (имеют ссылку в Phantom, но не в Weak), и я бы проверил, закрыты ли они или нет.
• Если вы добавите некоторую информацию об отладке/вызывающем объекте/стеке во время обслуживания ресурса, будет легче отследить утечку тестового примера.

Это также зависит от того, хотите ли вы использовать этот механизм в продакшене или нет — возможно, стоит добавить эту функцию в вашу библиотеку, потому что управление ресурсами будет проблемой и в продакшене. В этом случае вам не нужна оболочка, но вы можете расширить свои текущие классы с помощью этой функции. Вместо демонтажа вы можете использовать фоновый поток для регулярных проверок.

Что касается ссылочных типов, я рекомендую эта ссылка. PhantomReferences рекомендуется использовать для очистки ресурсов.

я бы предоставил экземпляры для этих объектов через Factory methods, и с этим я контролирую их создание, и я буду кормить потребителей с помощью Proxies, который выполняет логику закрытие объекта

interface Service<T> {
 T execute();
 void close();
}

class HeavyObject implements Service<SomeObject> {
  SomeObject execute() {
  // .. some logic here
  }
  private HeavyObject() {}

  public static HeavyObject create() {
   return new HeavyObjectProxy(new HeavyObject());
  }

  public void close() {
   // .. the closing logic here
  }
}

class HeavyObjectProxy extends HeavyObject {

  public SomeObject execute() {
    SomeObject value = super.execute();
    super.close();
    return value;
  }
}

В общем, если бы вы могли надежно проверить, был ли закрыт ресурс, вы могли бы просто закрыть его самостоятельно.

Первое, что нужно сделать, это упростить работу с ресурсом для клиента. Используйте идиому Execute Around.

Насколько я знаю, единственное использование execute вокруг для обработки ресурсов в библиотеке Java — это java.security.AccessController.doPrivileged, и это особенное (ресурс — это волшебный фрейм стека, который вы В самом деле не хотите оставлять открытым). Я считаю, что у Spring уже давно есть столь необходимая библиотека JDBC для этого. Я определенно использовал execute-around (в то время не знал, что это так называется) для JDBC вскоре после того, как Java 1.1 сделала его смутно практичным.

Код библиотеки должен выглядеть примерно так:

@FunctionalInterface
public interface WithMyResource<R> {
    R use(MyResource resource) throws MyException;
}
public class MyContext {
// ...
    public <R> R doAction(Arg arg, WithMyResource<R> with) throws MyException {
        try (MyResource resource = acquire(arg)) {
            return with.use(resource);
        }
    }

(Получите объявления параметров типа в нужном месте.)

Использование на стороне клиента выглядит примерно так:

MyType myResult = yourContext.doContext(resource -> {
    ...blah...;
    return ...thing...;
});

Вернемся к тестированию. Как упростить тестирование, даже если испытуемый извлекает ресурс из среды выполнения или доступен какой-то другой механизм?

Очевидный ответ заключается в том, что вы предоставляете решение для выполнения теста. Вам нужно будет предоставить некоторый API-интерфейс для выполнения, чтобы убедиться, что все ваши ресурсы, которые были получены в области, также были закрыты. Это должно быть связано с контекстом, из которого получен ресурс, а не с использованием глобального состояния.

В зависимости от того, какую среду тестирования используют ваши клиенты, вы можете предложить что-то лучшее. JUnit5, например, имеет средство расширения на основе аннотаций, которое позволяет вам предоставлять контекст в качестве аргумента, а также применять проверки после выполнения каждого теста. (Но я им мало пользовался, так что больше ничего не скажу.)