從Java 7開始，我們可以使用try-with-resources并自動關閉任何實現Autocloseable接口的對象。 如果資源是 Autocloseable 。 一些類需要一些總結，但不是Autocloseable 。 這些主要是某些遺留框架中的舊類，仍然妨礙我們前進。 沒有人再使用Struts了，但是仍然有足夠多的舊框架潛伏在黑暗中，我們必須使用它們。 我最近有這種經驗，而且我非常有動力，所以我創建了一個簡單的AutoCloser類。

我們可能有一個遺留類（在示例中，這是測試類的模擬內部類）

public class NotAutoclosable { public NotAutoclosable() { opened = true ; } public void dispose() { opened = false ; } }

顧名思義，它不是自動關閉的。 它沒有實現Autocloseable接口，并且沒有close()方法。 必須調用適當命名的方法dispose()來處置它。 （ opened的boolean字段用于稍后在單元測試中進行檢查，以斷言AutoCloser類的正確功能。）

該類的用法如下：

@Test void test() { final NotAutoclosable notAu; try ( final var s = AutoCloser.useResource( new NotAutoclosable()) .closeWith(sp -> sp.get().dispose())) { Assertions.assertTrue(opened); } Assertions.assertFalse(opened); }

我們使用內部類的構造函數創建資源，并定義將“關閉”資源的Consumer 。 該使用者將獲得與變量s存儲的相同的Supplier 。

旁注：此函數參數必須是使用者，并且不能使用變量s成為Runnable ，因為在將lambda表達式評估為lambda表達式時，不會初始化該變量。 當將要使用它時，它已經被定義了，但是對于Java編譯器來說為時已晚，它并不那么信任程序員，通常情況下，它有充分的理由做到這一點。

AutoCloser類如下：

public class AutoCloser<T> { private final T resource; private AutoCloser(T resource) { this .resource = resource; } public static <T> AutoCloser<T> useResource(T resource) { return new AutoCloser<>(resource); } public AutoClosableSupplier closeWith(Consumer<Supplier<T>> closer){ return new AutoClosableSupplier(closer); } public class AutoClosableSupplier implements Supplier<T>, AutoCloseable { private final Consumer<Supplier<T>> closer; private AutoClosableSupplier(Consumer<Supplier<T>> closer) { this .closer = closer; } @Override public T get() { return resource; } @Override public void close() { closer.accept( this ); } } }

之所以使用內部的AutoClosableSupplier類，是因為我們不希望程序員意外忘記指定最終將關閉資源的lambda。

這真的沒有什么嚴重的。 這只是一種編程風格，它類似于Go語言中的deferred語句，將資源的關閉移到了資源的打開處。

翻譯自: https://www.javacodegeeks.com/2019/05/box-old-objects-autoclosable.html

總結

以上是生活随笔為你收集整理的将旧对象装箱可自动关闭的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。