streamalism.org

1. Oversigt

Længe før Java WatchService API blev frigivet i Java 7, Apache Commons IO-overvågningsbiblioteket adresserede allerede det samme brugstilfælde ved overvågning af et filsystems placering eller bibliotek for ændringer.

I denne artikel vil vi undersøge forskellene mellem de to API'er.

2. Maven-afhængigheder

For at bruge Apache Commons IO skal følgende afhængighed tilføjes i pom:

 commons-io commons-io 2.5 

Og selvfølgelig er urtjenesten en del af JDK, så den behøver ingen ekstern afhængighed.

3. Sammenligning af funktioner

3.1. Begivenhedsstyret behandling

WatchService API styres af filsystemændringshændelser udløst af operativsystemet. Denne tilgang gemmer applikationen fra at afstemme filsystemet gentagne gange for ændringer.

Apache Commons IO Monitor-bibliotek på den anden side afspørger filsystemets placering ved et konfigurerbart søvninterval ved at ringe til listFiles () metode til Fil klasse. Denne tilgang spilder CPU-cyklusser, især hvis der ikke sker nogen ændring.

3.2. Tilbagekaldsmetode

WatchService API giver ikke tilbagekaldsmetoder. I stedet giver den to typer afstemningsmetoder til at kontrollere, om nye ændringer er tilgængelige til behandling:

1. Blokeringsmetoder som afstemning() (med en timeout-parameter) og tage()
2. Ikke-blokerende metode som afstemning() (uden timeout-parameter)

Med blokeringsmetoderne begynder applikationstråden kun at blive behandlet, når nye ændringshændelser er tilgængelige. Derfor behøver det ikke fortsætte med at stemme for nye begivenheder.

Detaljerne og brugen af ​​disse metoder kan findes i vores artikel her.

I modsætning hertil giver Apache Commons IO-bibliotek tilbagekaldsmetoder på FileAlterationListener grænseflade, der påberåbes, når der registreres en ændring i filsystemets placering eller bibliotek.

FileAlterationObserver observatør = ny FileAlterationObserver ("pathToDir"); FileAlterationMonitor monitor = ny 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 til behandling af ændringshændelse}}; observer.addListener (lytter); monitor.addObserver (observatør); monitor.start ();

3.3. Begivenhedsoverløb

WatchService API er drevet af operativsystemhændelserne. Derfor er der en mulighed for, at operativsystembufferen, der holder begivenhederne, overløber, hvis applikationen ikke kan behandle begivenhederne hurtigt nok. I dette scenario, begivenheden StandardWatchEventKinds.OVERFLOW udløses, hvilket indikerer, at nogle af begivenhederne går tabt eller kasseres, før applikationen kunne læse dem.

Dette kræver korrekt håndtering af FLYDE OVER hændelse i applikationen for at sikre, at applikationen kan håndtere enhver pludselig burst af ændringer, der kan udløse FLYDE OVER begivenhed.

Commons IO-biblioteket er derimod ikke baseret på operativsystemhændelser, og der er derfor ikke tale om overløb.

I hver afstemning får observatøren listen over filer i biblioteket og sammenligner den med listen opnået fra den forrige afstemning.

1. Hvis der findes et nyt filnavn i den sidste afstemning, onFileCreate () påkaldes lytteren
2. Hvis et filnavn, der blev fundet i den forrige afstemning, mangler i fillisten fra den sidste afstemning, onFileDelete () påkaldes lytteren
3. Hvis der findes et match, kontrolleres filen for ændringer i attributter som sidst ændrede dato, længde osv. Hvis der registreres en ændring, onFileChange () påkaldes lytteren

4. Konklusion

I denne artikel er det lykkedes os at fremhæve de vigtigste forskelle i de to API'er.

Og som altid er den fulde kildekode til eksemplerne i denne artikel tilgængelig i vores GitHub-projekt.