streamalism.org

1. Oversikt

I denne opplæringen vil vi se nærmere på to typer singletons tilgjengelig i Jakarta EE. Vi forklarer og demonstrerer forskjellene og ser bruken som passer for hver enkelt.

La oss først se hva singler handler om før vi går inn i detaljene.

2. Singleton designmønster

Husk at en vanlig måte å implementere Singleton Pattern er med en statisk forekomst og privat konstruktør:

offentlig finaleklasse Singleton {privat statisk finale Singleton-forekomst = ny Singleton (); privat Singleton () {} offentlig statisk Singleton getInstance () {returinstans; }} 

Men akk, dette er egentlig ikke objektorientert. Og det har noen problemer med flere tråder.

CDI- og EJB-containere gir oss imidlertid et objektorientert alternativ.

3. CDI Singleton

Med CDI (Contexts and Dependency Injection) kan vi enkelt lage singletoner ved hjelp av @Singleton kommentar. Denne kommentaren er en del av javax.inject pakke. Den instruerer containeren til Instant singleton en gang og sender referansen til andre gjenstander under injeksjonen.

Som vi kan se, er implementering av singleton med CDI veldig enkelt:

@Singleton offentlig klasse CarServiceSingleton {// ...} 

Vår klasse simulerer en bilservicebutikk. Vi har mange forekomster av forskjellige Bils, men de bruker alle samme butikk for service. Derfor passer Singleton godt.

Vi kan bekrefte at det er samme forekomst med en enkel JUnit-test som spør konteksten for klassen to ganger. Merk at vi har en getBean hjelpermetode her for lesbarhet:

@Test offentlig ugyldig gittASingleton_whenGetBeanIsCalledTwice_thenTheSameInstanceIsReturned () {CarServiceSingleton one = getBean (CarServiceSingleton.class); CarServiceSingleton to = getBean (CarServiceSingleton.class); assertTrue (en == to); } 

På grunn av @Singleton merknad, vil containeren returnere samme referanse begge ganger. Hvis vi prøver dette med en vanlig administrert bønne, vil containeren imidlertid gi en annen forekomst hver gang.

Og mens dette fungerer det samme for begge javax.inject.Singleton eller javax.ejb.Singleton, det er en nøkkelforskjell mellom disse to.

4. EJB Singleton

For å lage en EJB-singleton bruker vi @Singleton kommentar fra javax.ejb pakke. På denne måten lager vi en Singleton Session Bean.

Vi kan teste denne implementeringen på samme måte som vi testet CDI-implementeringen i forrige eksempel, og resultatet blir det samme. EJB singletons, som forventet, gir den eneste forekomsten av klassen.

Derimot, EJB Singletons gir også tilleggsfunksjonalitet i form av containerstyrt samtidighetskontroll.

Når vi bruker denne typen implementering, sørger EJB-containeren for at tilgang til hver offentlige metode i klassen av en enkelt tråd om gangen. Hvis flere tråder prøver å få tilgang til den samme metoden, får bare en tråd bruke den mens andre venter på sin tur.

Vi kan bekrefte denne oppførselen med en enkel test. Vi introduserer en simulering av tjenestekø for våre singleton-klasser:

privat statisk int serviceQueue; public int service (Car car) {serviceQueue ++; Tråd. Søvn (100); car.setServiced (true); serviceQueue--; retur serviceQueue; } 

serviceQueue er implementert som et vanlig statisk heltall som øker når en bil "går inn" i tjenesten og reduseres når den "går". Hvis beholderen sørger for riktig låsing, bør denne variabelen være lik null før og etter tjenesten, og lik en under tjenesten.

Vi kan sjekke atferden med en enkel test:

@Test offentlig ugyldig nårEjb_thenLockingIsProvided () {for (int i = 0; i <10; i ++) {new Thread (new Runnable () {@Override public void run () {int serviceQueue = carServiceEjbSingleton.service (new Car ("Speedster) xyz ")); assertEquals (0, serviceQueue);}}). start (); } komme tilbake; } 

Denne testen starter 10 parallelle tråder. Hver tråd starter en bil og prøver å betjene den. Etter tjenesten hevder den at verdien av serviceQueue er tilbake til null.

Hvis vi for eksempel utfører en lignende test på CDI-singleton, vil testen vår mislykkes.

5. Konklusjon

I denne artikkelen gikk vi gjennom to typer singleton-implementeringer tilgjengelig i Jakarta EE. Vi så fordelene og ulempene med dem, og vi demonstrerte også hvordan og når vi skulle bruke hver enkelt.

Og som alltid er den komplette kildekoden tilgjengelig på GitHub.