Forskjeller mellom Java WatchService API og Apache Commons IO Monitor Library

1. Oversikt

Lenge før Java WatchService API ble utgitt i Java 7, Apache Commons IO Monitoring-biblioteket adresserte allerede den samme brukssaken til å overvåke en filsystemplassering eller katalog for endringer.

I denne artikkelen skal vi utforske forskjellene mellom de to API-ene.

2. Maven-avhengigheter

For å bruke Apache Commons IO, må følgende avhengighet legges til i pom:

 commons-io commons-io 2.5 

Og selvfølgelig er klokketjenesten en del av JDK, så den trenger ingen ekstern avhengighet.

3. Funksjonssammenligning

3.1. Hendelsesdrevet prosessering

WatchService API drives av filsystemendringshendelsene utløst av operativsystemet. Denne tilnærmingen sparer applikasjonen fra å avstemme filsystemet gjentatte ganger for endringer.

Apache Commons IO Monitor-bibliotek derimot, avstemmer filsystemplasseringen ved et konfigurerbart soveintervall ved å ringe listFiles () Metode av Fil klasse. Denne tilnærmingen kaster bort CPU-sykluser, spesielt hvis ingen endringer skjer.

3.2. Tilbakekallingsmetode

WatchService API gir ikke tilbakekallingsmetoder. I stedet gir den to typer avstemningsmetoder for å sjekke om nye endringshendelser er tilgjengelige for behandling:

  1. Blokkeringsmetoder som avstemming() (med en timeout-parameter) og ta()
  2. Ikke-blokkerende metode som avstemming() (uten tidsavbruddsparameter)

Med blokkeringsmetodene begynner søknadstråden bare å behandle når nye endringshendelser er tilgjengelige. Derfor trenger den ikke fortsette å stemme for nye begivenheter.

Detaljer og bruk av disse metodene finner du i vår artikkel her.

Derimot tilbyr Apache Commons IO-bibliotek tilbakekallingsmetoder på FileAlterationListener grensesnitt som blir påkalt når en endring i filsystemets plassering eller katalog oppdages.

FileAlterationObserver observatør = ny FileAlterationObserver ("pathToDir"); FileAlterationMonitor monitor = new FileAlterationMonitor (POLL_INTERVAL); FileAlterationListener lytter = ny FileAlterationListenerAdaptor () {@Override public void onFileCreate (File file) {// code for processing creation event} @Override public void onFileDelete (File file) {// code for processing deletion event} @Override public void onFileChange ( Filfil) {// kode for behandling av endringshendelse}}; observer.addListener (lytter); monitor.addObserver (observatør); monitor.start ();

3.3. Overflytelse av hendelser

WatchService API er drevet av operativsystemhendelsene. Derfor er det en mulighet for at operativsystembufferen som holder hendelsene overløper, hvis applikasjonen ikke kan behandle hendelsene raskt nok. I dette scenariet, hendelsen StandardWatchEventKinds.OVERFLOW utløses, noe som indikerer at noen av hendelsene går tapt eller kastes før applikasjonen kan lese dem.

Dette krever riktig håndtering av FLYTE hendelse i applikasjonen for å sikre at applikasjonen kan håndtere eventuelle plutselige endringer som kan utløse FLYTE begivenhet.

Commons IO-biblioteket er derimot ikke basert på operativsystemhendelsene, og det er derfor ikke snakk om overflow.

I hver avstemning får observatøren listen over filer i katalogen og sammenligner den med listen hentet fra forrige avstemning.

  1. Hvis et nytt filnavn ble funnet i den siste avstemningen, onFileCreate () påkalles lytteren
  2. Hvis et filnavn som ble funnet i forrige avstemning, mangler i fillisten hentet fra forrige avstemning, onFileDelete () påkalles lytteren
  3. Hvis det blir funnet et samsvar, kontrolleres filen for eventuelle endringer i attributter som sist endret dato, lengde osv. Hvis en endring oppdages, onFileChange () påkalles lytteren

4. Konklusjon

I denne artikkelen har vi klart å fremheve nøkkelforskjellene i de to API-ene.

Og som alltid er den fullstendige kildekoden for eksemplene som brukes i denne artikkelen tilgjengelig i vårt GitHub-prosjekt.


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