Különbségek a Java WatchService API és az Apache Commons IO Monitor Library között

1. Áttekintés

Jóval a Java előtt WatchService Az API-t a Java 7-ben adták ki, az Apache Commons IO Monitoring könyvtár már ugyanarra a felhasználási esettel foglalkozott, ha a fájlrendszer helyét vagy könyvtárát figyelte a változásokra.

Ebben a cikkben megvizsgáljuk a két API közötti különbségeket.

2. Maven-függőségek

Az Apache Commons IO használatához a következő függőséget kell hozzáadni a pom:

 commons-io commons-io 2.5 

És természetesen az őrszolgálat a JDK része, ezért nincs szüksége külső függőségre.

3. Funkciók összehasonlítása

3.1. Eseményalapú feldolgozás

WatchService Az API-t az operációs rendszer által kiváltott fájlrendszer-változás események vezérlik. Ez a megközelítés megmenti az alkalmazást a fájlrendszer ismételt lekérdezésétől a változásokhoz.

Az Apache Commons IO Monitor könyvtár viszont konfigurálható alvási időközönként lekérdezi a fájlrendszer helyét a listFiles () a metódusa File osztály. Ez a megközelítés pazarolja a CPU-ciklusokat, különösen, ha nem történik változás.

3.2. Visszahívási módszer

WatchService Az API nem nyújt visszahívási módszereket. Ehelyett kétféle lekérdezési módszert biztosít annak ellenőrzésére, hogy rendelkezésre állnak-e új változásesemények a feldolgozáshoz:

  1. Blokkolási módszerek, mint például közvélemény kutatás() (időkorlát paraméterrel) és vesz()
  2. Nem blokkoló módszer, mint közvélemény kutatás() (időkorlát paraméter nélkül)

A blokkolási módszerekkel az alkalmazásszál csak akkor kezdi meg a feldolgozást, amikor új változásesemények állnak rendelkezésre. Ezért nem kell tovább szavaznia az új eseményekről.

Ezen módszerek részletei és felhasználása itt található cikkünkben találhatók.

Ezzel szemben az Apache Commons IO könyvtár visszahívási módszereket biztosít a FileAlterationListener interfész, amelyekre a fájlrendszer helyének vagy könyvtárának változásának észlelésekor kerül sor.

FileAlterationObserver observer = új FileAlterationObserver ("pathToDir"); FileAlterationMonitor monitor = új FileAlterationMonitor (POLL_INTERVAL); FileAlterationListener listener = new FileAlterationListenerAdaptor () {@Override public void onFileCreate (File file) {// code for creation esemény feldolgozásához Fájlfájl) {// kód a változásesemény feldolgozásához}}; megfigyelő.addListener (hallgató); monitor.addObserver (megfigyelő); monitor.start ();

3.3. Esemény túlcsordulás

WatchService Az API-t az operációs rendszer eseményei vezérlik. Ezért fennáll annak a lehetősége, hogy az eseményeket tartó operációs rendszer puffer túlcsordul, ha az alkalmazás nem tudja elég gyorsan feldolgozni az eseményeket. Ebben a forgatókönyvben az esemény StandardWatchEventKinds.OVERFLOW elindul, jelezve, hogy egyes események elvesznek vagy eldobásra kerülnek, mielőtt az alkalmazás elolvashatja őket.

Ez megköveteli a TÚLCSORDULÁS esemény az alkalmazásban annak biztosítása érdekében, hogy az alkalmazás képes legyen kezelni a hirtelen bekövetkező változáseseményeket, amelyek kiválthatják a TÚLCSORDULÁS esemény.

A Commons IO könyvtár viszont nem az operációs rendszer eseményein alapul, ezért nincs szó túlcsordulásról.

Minden szavazás során a megfigyelő megkapja a könyvtárban található fájlok listáját, és összehasonlítja az előző szavazás során kapott listával.

  1. Ha az utolsó szavazás során új fájlnév található, onFileCreate () meghallgatja
  2. Ha az előző közvélemény-kutatásban talált fájlnév hiányzik az utolsó szavazásból származó fájllistáról, onFileDelete () meghallgatja
  3. Ha talál egyezést, akkor a fájlt ellenőrizzük az attribútumok, például a legutóbbi módosítás dátumának, hosszának stb. onFileChange () meghallgatja

4. Következtetés

Ebben a cikkben sikerült kiemelnünk a két API legfontosabb különbségeit.

És mint mindig, a cikkben használt példák teljes forráskódja elérhető a GitHub projektünkben.


$config[zx-auto] not found$config[zx-overlay] not found