Asynchronous-IO vs Asynchronous-Request Processing in java

I denne artikel forsøger jeg at forklare forskellen mellem Async-IO og Async-Request-behandling i HTTP-anmodningen i Java-verdenen.

I verdenen før Java 1.4 leverer Java en API til at sende / modtage data via netværksstikket. De originale forfattere af JVM kortlagde denne API-opførsel til OS-socket API, næsten en til en.

Så hvad er OS-stikkontakten? OS leverer Socket programmering api, som har send / recv blokerende opkald . Da java kun er en proces, der kører oven på linux (OS), skal dette java-program derfor bruge denne blokerende API, der leveres af OS.

Verden var glad, og java-udviklere begyndte at bruge API'en til at sende / modtage dataene. Men de var nødt til at beholde en javatråd til hver sokkel (klient).

Alle skrev deres egen smag af HTTP-servere. Kodedeling blev hård, java-verdenen krævede en standardisering.

Indtast Java servlet Spec.

Før vi går videre, kan vi definere få udtryk:

Java Server Developer : Folk, der bruger java socket api og implementerer http-protokol som tomcat.

java Application Developer: Mennesker, der bygger forretningsapplikationer oven på tomcat.

TILBAGE NU

Når java servlet spec kom ind i verden, sagde det:

Kære Java-serverudviklere. Angiv venligst en metode som nedenfor:

doGet(inputReq, OutPutRes)

java applikationsudvikler kan implementere, doGetog de kan skrive deres forretningslogik. Når "applikationsudvikler" vil sende den response, kan han ringeOutPutRes.write().

En ting at bemærke: Da socket api blokerer, blokerer OutPutRes.write () derfor også. Den yderligere begrænsning var også, at responsobjektet er begået ved afslutning af doGet-metoden .

På grund af disse begrænsninger måtte folk bruge en tråd til at behandle en anmodning.

Tiden gik, og internettet overtog verden. en tråd pr. anmodning begyndte at vise begrænsninger.

Opgave 1:

Tråden pr. Anmodning-model mislykkes, når der er lange pauser under behandlingen af ​​hver anmodning.

For eksempel: hentning af data fra undertjeneste tager lang tid.

Under en sådan situation sidder tråden for det meste inaktiv, og JVM kan let løbe tør for tråd.

Opgave 2:

Ting blev endnu værre med http1.1 vedvarende forbindelse. Som med vedvarende forbindelse holdes den underliggende TCP-forbindelse i live, og serveren skal blokere en tråd pr. Forbindelse.

Men hvorfor skal serveren blokere en tråd pr. Forbindelse?

Da OS tilvejebringer et blokerende stik Recv api, skal jvm kalde OS-blokerende Recv-metoden for at lytte efter flere anmodninger om samme TCP-forbindelse fra klienten.

Verden krævede en løsning!

Den første løsning kom fra skaberen af ​​JVM. De introducerede NIO ( ASYNC-IO ). Nio er den ikke-blokerende API til at sende / modtage data via socket.

Nogle baggrund: denOS sammen med blokerende socket api giver også en ikke-blokerende version af socket api.

Men hvordan leverer operativsystemet det .. Gafler det en tråd internt, og den tråden bliver blokeret ???

SVARET er nej ... OS instruerer hardwaren om at afbryde, når der er data at læse eller skrive.

NIO tillod " Java-serverudvikleren"for at tackle problem 2 med at blokere en tråd pr. TCP-forbindelse . Da NIO er en HTTP-vedvarende forbindelse, behøver tråden ikke, at den blokerer ved recv- opkald. I stedet kan det nu kun behandle det, når der er data, der skal behandles. Dette tillod en tråd at overvåge / håndtere et stort antal vedvarende forbindelser.

Den anden løsning kom fra servlet spec. Servlet Spec fik en opgradering, og de introducerede async-support (Async Request Processing).

AsyncContext acontext = req.startAsync();
VIGTIGT: Denne opgradering fjernede begrænsningen med at begå responsobjektet ved afslutning af doGet- metoden.

Dette gjorde det muligt for " Java Application Developer" at tackle problem 1 ved at aflade arbejde til baggrundstråde. Nu i stedet for at lade tråden vente under den lange pause, kan tråden bruges til at håndtere andre anmodninger.

KONKLUSION:

Async-IO i java bruger dybest set den ikke-blokerende version på OS socket API.

Behandling af Async-anmodninger er grundlæggende standardiseringen af ​​servletspecifikation for, hvordan man behandler flere anmodninger med en tråd.

REFERENCER:

//www.scottklement.com/rpg/socktut/tutorial.pdf

//stackoverflow.com/questions/15217524/what-is-the-difference-between-thread-per-connection-vs-thread-per-quest

Motivation af artiklen: Team Learning / Knowledge Sharing