Memo zur Überwachungsmethode für Verzeichnisänderungen (Java, Kotlin)

Wie man Javas WatchService benutzt, habe ich mir notiert, weil es unerwartet passte, als ich mit einem leichten Gefühl anfing. Der Code ist Kotlin, aber ist er in Java der gleiche?

class Watcher private constructor(
        val path: Path,
        val listener: (e: WatchEvent<Path>, target: Path) -> Unit
) : AutoCloseable {

    private val executor = Executors.newSingleThreadExecutor()
    private val watchService = path.fileSystem.newWatchService()

    init {
        val watchKey = path.register(watchService, ENTRY_CREATE, ENTRY_DELETE, ENTRY_MODIFY)

        executor.submit {
            while (true) {
                val key = watchService.take()
                assert(watchKey == key, { "Es ist nur ein Schlüssel registriert, daher sollte er immer übereinstimmen" })

                for (e in watchKey.pollEvents()) {
                    @Suppress("UNCHECKED_CAST")  //Immer wenn das WatchKey-Ereignis oben ist, ist es garantiert Path
                    listener(
                            e as WatchEvent<Path>,
                            path.resolve(e.context())
                    )
                }
                val valid = watchKey.reset()
                if (!valid) throw RuntimeException("Sollte nicht normal passieren")
            }
        }
    }

    override fun close() {
        executor.shutdownNow()
        executor.awaitTermination(1, TimeUnit.SECONDS)  //Dieser Wert ist angemessen
        watchService.close()
    }

    companion object {
        fun watch(
                path: Path,
                listener: (e: WatchEvent<Path>, target: Path) -> Unit
        ): Watcher {
            return Watcher(path, listener)
        }
    }

}

Punkt

• Die Überwachung erfolgt in einem separaten Thread mit ExecutorService. Weil WatchService.take () blockiert, bis eine Änderung erkannt wird. poll () blockiert nicht und gibt null zurück, aber in jedem Fall ist es bequemer, dies in einem separaten Thread zu tun.
• WatchKey.pollEvents () gibt eine Liste von Wildcarded WatchEvents zurück. "WatchEvent.context ()" ist jedoch Dokument und das Ereignis Es wird garantiert immer "Pfad" zurückgegeben, solange einer von "ENTRY_CREATE", "ENTRY_DELETE", "ENTRY_MODIFY" vorhanden ist. Kurz gesagt, es wird immer "Pfad" sein, so dass es kein Problem gibt, es bedingungslos zu wirken.
• Der von WatchEvent.context () zurückgegebene Pfad wird als relativer Pfad aus dem überwachten Verzeichnis zurückgegeben. Wenn Sie versuchen, den zurückgegebenen "Pfad" so zu verwenden, wie er ist, wird daher versucht, die Datei basierend auf dem aktuellen Verzeichnis zu finden. Daher kann die Datei nicht gefunden werden (es sei denn, das Überwachungsverzeichnis ist aktuell) und eine Ausnahme wird ausgelöst. Dieses Verhalten ist eher unintuitiv und unpraktisch, sodass dem Listener ein separater "Pfad" zurückgegeben wird, der in den "Pfad" des überwachten Verzeichnisses aufgelöst wird.
• Setzen Sie die Überwachung mit "WatchKey.reset ()" fort. Der Rückgabewert gibt an, ob das Zurücksetzen erfolgreich war, aber soweit Sie [Dokument] gelesen haben (https://docs.oracle.com/javase/jp/9/docs/api/java/nio/file/WatchKey.html) Es sieht fast genauso aus wie "isValid ()". Die Bedingung, dass der Schlüssel gültig ist, ist

1. Explizit abgebrochen durch Aufrufen der Abbruchmethode
2. Implizit abgebrochen, da auf das Objekt nicht mehr zugegriffen werden kann
3. Abgebrochen durch Schließen des Überwachungsdienstes

Also, dieser Code passiert normalerweise nicht ...

• Nach dem Erstellen einer Datei usw. dauert es einige Zeit, bis "WatchService.take ()" einen Wert zurückgibt (ca. 5 Sekunden in meiner Umgebung). langsam.

Verbesserungsplan

• Rückrufausführung an einen anderen Thread
• Versuchen Sie automatisch "close ()", wenn keine Referenzen mehr vorhanden sind
• Ist der Überwachungsthread jedem "Beobachter" gemeinsam?

Impressionen

Schwer zu benutzen ...