🕰️ 📨 👰🏿 JavaマシンからDLLをアンロードする方法 🥧 😶 🛵

Javaは、System.loadLibrary（）プロシージャによってロードされたシステムライブラリを使用して、ネイティブキーワードでマークされたメソッドを介してオペレーティングシステムと対話します。

システムライブラリのダウンロードは非常に簡単ですが、結果としてアンロードするには、多くの努力が必要です。システムライブラリがどのくらい正確にアンロードされ、なぜそれが必要なのかを教えてみます。

ユーザーがローカルネットワーク上のコンピューターで実行する小さなユーティリティを作成するとします。プログラムのインストールと構成に関する問題からユーザーを救いたいのですが、集中型インフラストラクチャを展開して維持するためのリソースはありません。このような場合、通常、すべての依存関係とともにプログラムを1つのjarファイルにアセンブルします。これは、maven-assembly-pluginを使用するか、IDE Runnable jarからエクスポートするだけで簡単です。次のコマンドでプログラムが起動します。

java -jar my-program.jar

残念ながら、ライブラリの1つがその動作にシステム動的ライブラリ、つまりdllを必要とする場合、これは機能しません。通常、このようなライブラリのクラスの1つでは、静的初期化子でSystem.loadLibrary（）の呼び出しが行われます。 dllをロードするには、JVMシステムプロパティjava.library.pathからアクセスできるディレクトリに配置する必要があります。この回避策はどのように回避できますか？

jarファイル内にdllをパックします。 dllのロードを必要とするクラスの使用を開始する前に、一時ディレクトリを作成し、そこにライブラリを抽出して、ディレクトリをjava.library.pathに追加します。次のようになります。

prepareLibrary

 private void addLibraryPath(String pathToAdd) throws ReflectiveOperationException { Field usrPathsField = ClassLoader.class.getDeclaredField("usr_paths"); usrPathsField.setAccessible(true); String[] paths = (String[]) usrPathsField.get(null); String[] newPaths = Arrays.copyOf(paths, paths.length + 1); newPaths[newPaths.length - 1] = pathToAdd; usrPathsField.set(null, newPaths); } private Path prepareLibrary() throws IOException, ReflectiveOperationException { Path dir = Files.createTempDirectory("lib"); try (InputStream input = ExampleClass.class.getResourceAsStream("custom.dll")) { if (input == null) { throw new FileNotFoundException("Can't load resource custom.dll"); } Files.copy(input, dir.resolve("custom.dll")); } addLibraryPath(dir.toAbsolutePath().toString()); return dir; }

残念ながら、Java は java.library.pathを拡張する標準メソッドを提供していないため、リフレクションで化学化する必要があります。

ライブラリのロードはユーザーにとって透過的であり、ファイルのコピーや環境変数の設定について心配する必要はありません。動作するには、通常のスクリプトを実行するだけで十分です。ただし、プログラムを開始するたびに、ファイルのある一時ディレクトリが残ります。これはあまり良くないので、出力をきれいにしなければなりません。

 try { ... } finally { delete(dir); }

しかし、Windowsではこれは機能しません。 JVMにロードされたライブラリは、dllファイルとそれが存在するディレクトリをロックします。したがって、プログラムを正確に終了する問題を解決するには、JVMからシステム動的ライブラリをアンロードする必要があります。

解決しよう

まず、コードに診断を追加するのが妥当です。たとえば、ファイルが削除された場合。ライブラリが使用されなかった場合、何もする必要はありません。ファイルがロックされている場合は、追加の対策を講じてください。

 if (!delete(dir)) { forceDelete(dir); }

迅速ではあるが最も美しいソリューションではないため、スケジューラを使用しました。出力で、1分後にcmd / c rd / s / q temp-dirコマンドを実行するタスクを含むxmlファイルを作成し、schtasks -create taskName -xml taskFile.xmlコマンドを使用してタスクをスケジューラにロードします。タスクが完了するまでに、プログラムは既に完了しており、ファイルを保持しているユーザーはいません。

最も正しい決定は、Javaマシンを使用してライブラリーをアンロードすることです。ドキュメントには、クラスが削除されるとシステムライブラリがアンロードされ、クラスのインスタンスが1つも残っていない場合、クラスローダーとともにクラスがガベージコレクターによって削除されると書かれています。私の意見では、すべてのメモリと他のリソースを完全にクリーンアップするようなコードを常に記述する方が良いと思います。コードが何か役に立つ場合は、遅かれ早かれコードを再利用して、他のコンポーネントがインストールされているサーバーにデプロイする必要があるためです。そこで、プログラムを使用してdllを正しくアンロードする方法を見つけるために時間をかけることにしました。

クラスローダーを使用する

私のプログラムでは、問題はJDBCドライバーに起因しているため、JDBCの例を引き続き見ていきます。ただし、同様の方法で他のライブラリを操作できます。

dllがシステムクラスローダーからロードされると、アンロードできなくなります。そのため、ライブラリをプルするクラスがロードされるようにクラスローダーを作成する必要があります。新しいクラスローダーは、親プロパティを介してシステムクラスローダーに接続する必要があります。そうしないと、文字列、オブジェクト、およびエコノミーに必要なその他のものが使用できなくなります。

試してみましょう：

新しいブートローダーからクラスをロードする（1）

 ClassLoader parentCl = ExampleClass.class.getClassLoader(); classLoader = new URLClassLoader(new URL[0], parentCl); Class.forName("org.jdbc.CustomDriver", classLoader, true); try (Connection connection = DriverManager.getConnection(dbUrl, dbProperties)) { if (connection.getClass().getClassLoader() != classLoader) { System.out.printf("-   %n"); } ... }

動作しません。クラスをロードするとき、最初に親ローダーからクラスを持ち上げようとするため、ドライバーは必要に応じてロードしませんでした。新しいクラスローダーを使用するには、プログラムjarファイルからJDBCドライバーを削除して、システムローダーからアクセスできないようにする必要があります。そのため、ライブラリを埋め込みjarファイルの形式でパックし、使用する前に一時ディレクトリ（dllが存在する場所と同じ場所）に展開します。

新しいブートローダーからのクラスの読み込み（2）

 ClassLoader cl = ExampleClass.class.getClassLoader(); URL url = UnloadableDriver.class.getResource("CustomJDBCDriver.jar"); if (url == null) { throw new FileNotFoundException("Can't load resource CustomJDBCDriver.jar"); } Path dir = prepareLibrary(); try (InputStream stream = url.openStream()) { Path target = dir.resolve("CustromJDBCDriver.jar"); Files.copy(stream, target); url = target.toUri().toURL(); } ClassLoader classLoader = new URLClassLoader(new URL[] {url}, cl); Class.forName("org.jdbc.CustomDriver", true, classLoader); try (Connection connection = DriverManager.getConnection(dbUrl, dbProperties)) { if (connection.getClass().getClassLoader() != classLoader) { System.out.printf("-   %n"); } else { System.out.printf(",   %n"); } ... }

新しいブートローダーからオブジェクトをロードしました。作業の最後に、開いたすべてのものを閉じ、すべての変数をクリーンアップし、明らかにSystem.gc（）を呼び出します。その後、ファイルのクリーンアップを試みます。この時点で、明示的な初期化メソッドを使用して、クラスローダーを操作するロジック全体を別のクラスにカプセル化することは理にかなっています。

メインクラスのスケルトン

 public class ExampleClass implements AutoCloseable { private final Path dir; private URLClassLoader classLoader; public ExampleClass() { ... } public void doWork() { ... } @Override public void close() { ... this.classLoader.close(); this.classloader = null; System.gc(); // -    dll if (!delete(this.dir)) { scheduleRemovalToTaskschd(this.dir); } } } public class Main { public static void main(String args[]) { try (ExampleClass example = new ExampleClass()) { example.doWork(); } catch (Throwable e) { e.printStackTrace(); } } }

ガベージコレクターの実験

ライブラリのアンロードにはすべてが正式に必要と思われるという事実にもかかわらず、実際にはアンロードは行われません。 java.langパッケージからソースを読み取ることで、ネイティブライブラリの削除が、内部クラスのいずれかのfinalize（）メソッドで行われていることを確認できました。ドキュメントには、このメソッドがいつ実行されるのか、まったく実行されるのかについての正確な定義が示されていないため、これは苦痛であり、驚くべきことです。つまり、成功は、さまざまな環境、さまざまなバージョンのJVM、またはさまざまなガベージコレクターで異なる可能性のあるいくつかの要因に依存します。ただし、希望を与えるSystem.runFinalization（）メソッドがあります。

私達は試みます：

ファイナライズを実行...

 @Override public void close() { ... this.classLoader.close(); this.classloader = null; System.gc(); System.runFinalization(); // -    dll if (!delete(this.dir)) { scheduleRemovalToTaskschd(this.dir); } }

動作しません。ディレクトリはJavaプロセスによってロックされています。これからこのテクニックを使用しました。

System.in.read（）を出力に配置しました
プログラムがこの場所で停止すると、jvisualvmからメモリダンプを作成します
Eclipse Memory Analysis Toolまたはjhatを使用してダンプを監視する
クラスがローダーによってロードされたオブジェクトのインスタンスを探しています

漏れの原因は5つありました。

ローカル変数
ドライバーマネージャー
リソースバンドル
スレッドローカル
例外

ローカル変数

ローカル変数

ガベージコレクターは、変数がスコープ外になった場合でも、この変数を含む関数が完了するまで、ローカル変数が到達不能であるとは見なさないことが判明しました。

 if (needConnection) { try (Connection connection = DriverManager.connect()) { ... } } //    connection   .

したがって、クラスローダーのアンロードの問題を解決するには、gcを呼び出す前に、アンロードされたクラスを使用するすべての関数を終了する必要があります。

ドライバーマネージャー

ドライバーマネージャー

クラスをロードすると、JDBCドライバーはregisterDriver（）メソッドによってDriverManagerクラスに登録されます。どうやら、アンロードする前に、deregisterDriver（）メソッドを呼び出す必要があります。やってみます。

 Enumeration<Driver> drivers = driverManager.getDrivers(); while (drivers.hasMoreElements()) { Driver driver = drivers.nextElement(); if (driver.getClass().getClassLoader() == classLoader) { DriverManager.deregisterDriver(driver); break; } }

動作しません。 Heapdumpは変更されていません。 DriverManagerクラスのソースコードを確認すると、deregisterDriver（）メソッドは、registerDriver（）を呼び出したクラスと同じクラスローダーに属するクラスからの呼び出しでなければならないことを確認します。そしてregisterDriver（）は、静的初期化子からドライバー自体によって呼び出されます。予想外のターン。

ドライバーを直接登録解除できないことがわかりました。代わりに、新しいクラスローダーのクラスに自分の代わりに実行するよう依頼する必要があります。方法は、特別なDriverManagerProxyクラス、さらに正確には2つのクラスとインターフェースを作成することです。

 public interface DriverManagerProxy { void deregisterDriver(Driver driver) throws SQLException; } public class DriverManagerProxyImpl implements DriverManagerProxy { @Override public void deregisterDriver(Driver driver) throws SQLException { DriverManager.deregisterDriver(driver); } }

インターフェースはメインのクラスパスにあり、実装はJDBCドライバーとともに補助jarファイルから新しいローダーによってロードされます。理論的には、インターフェイスを省くことができますが、関数を呼び出すにはリフレクションを使用する必要があります。プロキシは次のように使用されます。

DriverManagerProxyを使用する

 public class ExampleClass implements AutoCloseable { private final Path dir; private URLClassLoader classLoader; private DriverManagerProxy driverManager; public ExampleClass() { ... this.classLoader = ...; Class.forName("org.jdbc.CustomDriver", true, classLoader); Class<?> dmClass = Class.forName("ru.example.DriverManagerProxyImpl", true, classLoader); this.driverManager = (DriverManagerProxy) dmClass.newInstance(); } public void doWork() { ... } @Override public void close() { ... Enumeration<Driver> drivers = driverManager.getDrivers(); while (drivers.hasMoreElements()) { Driver driver = drivers.nextElement(); if (driver.getClass().getClassLoader() == classLoader) { driverManager.deregisterDriver(driver); break; } } this.driverManager = null; this.classLoader.close(); this.classloader = null; System.gc(); System.runFinalization(); // -    dll if (!delete(this.dir)) { scheduleRemovalToTaskschd(this.dir); } } }

リソースバンドル

リソースバンドル

私がアンロードしようとした次のクラスローダーの手がかりは、ResourceBundleクラスの腸で見つかりました。さいわい、DriverManagerとは異なり、ResourceBundleには特別な関数clearCache（）が用意されており、クラスローダーがパラメーターとして渡されます。

 ResourceBundle.clearCache(classLoader);

ソースによって判断すると、ResourceBundleはガベージコレクションに干渉してはならない弱いリンクを使用することに注意してください。おそらく、オブジェクトへの他のすべてのリンクをクリアする場合、このキャッシュをクリアする必要はありません。

スレッドローカル

スレッドローカル

未使用のドライバーの末尾が最後に現れたのは、ThreadLocalsでした。 DriverManagerの話の後、ローカルスレッド変数をクリアすることは、いくつかの些細なことのように思えます。反省せずにはできませんでしたが。

 private static void cleanupThreadLocals(ClassLoader cl) throws ReflectiveOperationException { int length = 1; Thread threads[] = new Thread[length]; int cnt = Thread.enumerate(threads); while (cnt >= length) { length *= 2; threads = new Thread[length]; cnt = Thread.enumerate(threads); } for (int i = 0; i < cnt; i++) { Thread thread = threads[i]; if (thread == null) { continue; } cleanupThreadLocals(thread, cl); } } private static void cleanupThreadLocals(Thread thread, ClassLoader cl) throws ReflectiveOperationException { Field threadLocalsField = Thread.class.getDeclaredField("threadLocals"); threadLocalsField.setAccessible(true); Object threadLocals = threadLocalsField.get(thread); if (threadLocals == null) { return; } Class<?> threadLocalsClass = threadLocals.getClass(); Field tableField = threadLocalsClass.getDeclaredField("table"); tableField.setAccessible(true); Object table = tableField.get(threadLocals); Object entries[] = (Object[]) table; Class<?> entryClass = table.getClass().getComponentType(); Field valueField = entryClass.getDeclaredField("value"); valueField.setAccessible(true); Method expungeStaleEntry = threadLocalsClass.getDeclaredMethod("expungeStaleEntry", Integer.TYPE); expungeStaleEntry.setAccessible(true); for (int i = 0; i < entries.length; i++) { Object entry = entries[i]; if (entry == null) { continue; } Object value = valueField.get(entry); if (value != null) { ClassLoader valueClassLoader = value.getClass().getClassLoader(); if (valueClassLoader == cl) { ((java.lang.ref.Reference<?>) entry).clear(); expungeStaleEntry.invoke(threadLocals, i); } } } }

例外

クリーンアップコードをfinallyブロックに配置できることを願っています。このブロックの入り口で、try-with-resourcesメカニズムを使用してすべてを自動的に閉じる必要があります。ただし、このクラスローダーによってクラスがロードされたtryブロックから例外がスローされた場合、クラスローダーはこのメモリから削除されません。

メモリから不要な例外を削除するには、キャッチして処理する必要があります。エラーをスローする必要がある場合は、例外を別のクラスにコピーします。これが私のプログラムでのやり方です：

 try { ... } catch (RuntimeException e) { if (e.getClass().getClassLoader() == this.getClass().getClassLoader()) { throw e; } RuntimeException exception = new RuntimeException(String.format("%s: %s", e.getClass(), e.getMessage())); exception.setStackTrace(e.getStackTrace()); throw exception; } catch (SQLException e) { if (e.getClass().getClassLoader() == this.getClass().getClassLoader()) { throw e; } SQLException exception = new SQLException(String.format("%s: %s", e.getClass(), e.getMessage())); exception.setStackTrace(e.getStackTrace()); throw exception; }

Javaの反撃

ページ化されたクラスへの検出されたすべての参照をクリアした後、少し矛盾した状況が判明しました。メモリダンプから判断すると、メモリ内にオブジェクトはありません。すべてのクラスのインスタンス数は0です。しかし、クラス自体とそのローダーは消えず、ネイティブライブラリはそれに応じて削除されませんでした。

この手法で問題を解決することが判明しました。

 System.gc(); System.runFinalization(); System.gc(); System.runFinalization();

おそらく、私が使用したJava 1.7では、PermGenにあるオブジェクトをクリーニングするという特殊性がありました。アプリケーションサーバーを含むさまざまな環境で同等に動作するコードを記述しようとしたため、ガベージコレクションの設定を試しませんでした。

指定された受信後、コードは適切に機能し、ライブラリがアンロードされ、ディレクトリが削除されました。ただし、Java 8に切り替えた後、問題が返されました。問題が何であるかを理解する時間はありませんでしたが、明らかに、ガベージコレクターの動作に何かが変更されました。

したがって、重砲、つまりJMXを使用する必要がありました。

Javaでゴミを収集する方法

 private static void dumpHeap() { try { Class<?> clazz = Class.forName("com.sun.management.HotSpotDiagnosticMXBean"); MBeanServer server = ManagementFactory.getPlatformMBeanServer(); Object hotspotMBean = ManagementFactory.newPlatformMXBeanProxy( server, "com.sun.management:type=HotSpotDiagnostic", clazz); Method m = clazz.getMethod("dumpHeap", String.class, boolean.class); m.invoke(hotspotMBean, "nul", true); } catch (@SuppressWarnings("unused") RuntimeException e) { return; } catch (@SuppressWarnings("unused") ReflectiveOperationException e) { return; } catch (@SuppressWarnings("unused") IOException e) { return; } }

HotSpotDiagnosticMXBeanを介して、ストレージダンプを呼び出します。ファイル名としてnulを指定します。これは、WindowsではUnixの/ dev / nullと同じことを意味します。 2番目のパラメーターは、ライブオブジェクトのみをダンプにアンロードする必要があることを示します。 JVMがフルガベージコレクションを完了するのは、このパラメーターです。

このライフハックの後、一時ディレクトリからライブラリを削除する問題は発生しなくなりました。最終的なファイルクリーンアップコードは次のようになります。

 this.classLoader = null; System.gc(); System.runFinalization(); System.gc(); System.runFinalization(); if (!delete(this.dir)) { dumpHeap(); if (!delete(this.dir)) { scheduleRemovalToTaskschd(this.dir); } }

OSGIによる検証

コードの品質を確認するために、JDBCドライバーを作成しました。これにより、完全にクリーンアップされます。別のクラスパスからロードされた他のドライバーのラッパーのように機能します。

UnloadableDriver

 public class UnloadableDriver implements Driver, AutoCloseable { private final Path dir; //  ,   private URLClassLoader classLoader; private DriverManagerProxy driverManager; private Driver driver; public UnloadableDriver() throws SQLException { ... } @Override public void close() { ... } ... }

このドライバーをApache FelixのOSGIサービスに挿入しました。

JDBCService

 public interface JDBCService { Connection getConnection(String url, Properties properties) throws SQLException; } @Service(JDBCService.class) public class JDBCServiceImpl implements JDBCService { private UnloadableDriver driver; @Activate public void activate(ComponentContext ctx) throws SQLException { this.driver = new UnloadableDriver(); } @Deactivate public void deactivate() { this.driver.close(); this.driver = null; } @Override public Connection getConnection(String url, Properties info) throws SQLException { return this.driver.connect(url, properties); } }

Java 1.8.0_102で実行されているApache Felixシステムコンソールからモジュールを起動すると、dllファイルを含む一時ディレクトリが表示されます。 Javaプロセスによってロックされたファイル。モジュールが停止するとすぐに、ディレクトリは自動的に削除されます。 UnloadableDriverを使用する代わりに、DriverManagerとEmbedded-Artifactsの通常のライブラリを使用する場合、モジュールの更新後、エラーjava.lang.UnsatisfiedLinkError：Native Libraryはすでに別のクラスローダーにロードされています。

結論

システムダイナミックライブラリをJavaマシンからアンロードする普遍的な方法はありませんが、この問題は解決されています。

Javaにはクラスへの参照を誤って残すことができる多くの場所があり、これはメモリリークの前提条件です。

コードがすべてを正しく実行したとしても、使用しているライブラリによってリークが発生する可能性があります。

実行時に作成される新しいクラスローダーを使用してプログラムが何かをロードする場合には、特に注意を払う必要があります。ロードされたクラスの1つへのリンクが少なくとも1つ残っている場合、クラスローダーとそのすべてのクラスはメモリに残ります。

メモリリークを検出するには、Eclipse MATなどの特別なツールを使用してダンプおよび分析する必要があります。

サードパーティのライブラリでメモリリークが検出された場合、この記事で説明されているレシピのいずれかを使用して、メモリリークを排除することができます。

JavaマシンからDLLをアンロードする方法