Servlet-haastattelun 40 parasta kysymystä ja vastausta (2026)
James Hartman
Valmistautuminen a Java Verkkohaastattelu tarkoittaa ennakointia, mitä servlet-käsitteitä työnantajat todella testaavat. Tämä opas selittää, miksi Servlet-haastattelu kysymykset ovat tärkeitä ja mitä syvempää ymmärrystä ne ammatillisesti paljastavat.
Vahva servlettien tuntemus avaa työpaikkoja alan aloittelijoille, keskitason ja kokeneille ammattilaisille. Rekrytoijat arvostavat teknistä kokemusta, toimialaosaamista ja todellisten projektien kautta hankittuja analysointitaitoja. Se auttaa tiimejä, esimiehiä ja kokeneita arvioimaan osaamisensa syvyyttä perus-, edistyneiden ja teknisten kysymysten ja vastausten osalta pitkän aikavälin ammatillisen kasvun aikana. Lue lisää ...
👉 Ilmainen PDF-lataus: Servlet-haastattelukysymykset ja vastaukset
Servlet-haastattelun tärkeimmät kysymykset ja vastaukset
1) Mikä on a Java Servletti?
A Java Servlet on palvelinpuolen komponentti, joka on kirjoitettu Java joka kulkee sisällä verkkosäiliö (kuten Apache Tomcat, Jetty tai Glassfish) ja käsittelee saapuvat HTTP-pyynnöt dynaamisten vastausten luomiseksi. Servletit yhdistävät tiedonsiirron asiakaspyyntöjen (yleensä selaimesta) ja taustaresurssien, kuten tietokantojen tai liiketoimintalogiikan, välillä. Kuten muutkin Java luokat, servletit hyötyvät alustariippumattomuudesta, turvallisuudesta ja vankoista ominaisuuksista Java ekosysteemin.
Esimerkiksi: Servlet voi käsitellä käyttäjän kirjautumislomakkeen ottamalla käyttäjätunnus- ja salasanaparametrit pyynnöstä, tarkistamalla ne tietokantaa vasten ja palauttamalla sitten HTML-sivun kirjautumistuloksen perusteella.
2) Mitkä ovat servlettien edut CGI:hin verrattuna?
Servleteillä on useita keskeisiä etuja verrattuna Common Gateway Interface (CGI) ohjelmat:
| Ominaisuus | Servletit | CGI |
|---|---|---|
| Käsitellä asiaa | Käsittelee pyyntöjä säikeiden avulla | Luo uuden prosessin pyyntöä kohden |
| Suorituskyky | Korkea | Matala |
| siirrettävyys | Java-pohjainen ja alustariippumaton | Riippuu natiiveista binääritiedostoista |
| Muistin käyttö | Tehokas | Korkea |
Servletit ovat kevyitä ja skaalautuvia, koska ne eivät luo uutta prosessia jokaista pyyntöä varten. CGI-skriptit sitä vastoin luovat erillisen prosessin joka kerta, mikä johtaa merkittävään ylimääräiseen työmäärään.
3) Selitä servletin elinkaari
Servletin elinkaari määrittelee servletin läpikäymät vaiheet luomisesta tuhoamiseen säilössä:
- Lataus ja instanssien luontiKontti lataa servletin ja kutsuu konstruktoria.
- Alustus:
init()kutsutaan kerran minkä tahansa käynnistyskonfiguraation suorittamiseksi. - Pyyntöjen käsittely:
service()metodia kutsutaan jokaiselle pyynnölle ja se delegoi metodille, kutendoGet()ordoPost(). - tuho:
destroy()kutsutaan ennen servletin poistamista, mikä mahdollistaa siivouksen.
Tämä elinkaari varmistaa resurssien tehokkaan käytön ja pyyntöjen yhdenmukaisen käsittelyn.
4) Mitä eroa on GenericServletin ja HttpServletin välillä?
GenericServlet ja HttpServlet ovat molemmat abstraktioita servlettien rakentamiseen:
- GenericServletProtokollasta riippumaton abstrakti luokka, joka käsittelee yleisiä pyyntö-/vastausmalleja.
- HttpServletAlaluokka
GenericServleterityisesti suunniteltu HTTP-protokolla, tarjoamalla menetelmiä, kutendoGet(),doPost(), Jne
Koska useimmat verkkosovellukset käyttävät HTTP:tä, HttpServlet on käytännössä paljon yleisempää.
5) Miten Servlet käsittelee HTTP GET- ja POST-pyyntöjä?
Servletit käyttävät eri metodeja palvelimen sisällä. HttpServlet luokka HTTP-pyyntöjen käsittelyyn:
doGet(HttpServletRequest req,HttpServletResponse res) kutsutaan GET-pyynnöille (yleensä datan hakemiseksi).doPost(HttpServletRequest req,HttpServletResponse res) on tarkoitettu POST-pyyntöihin (käytetään tyypillisesti lomakkeiden lähettämiseen tai palvelimen tilan muokkaamiseen).
service() menetelmä HttpServlet reitittää pyynnöt automaattisesti asianmukaiselle käsittelijälle HTTP-metodin perusteella.
6) Mikä on web.xml-tiedoston tarkoitus Servleteissä?
web.xml käyttöönottokuvaaja on verkkosovelluksen WEB-INF-hakemistoon sijoitettu määritystiedosto. Se yhdistää servlet-luokat URL-osoitteisiin, asettaa alustusparametrit, konfiguroi suodattimet ja kuuntelijat sekä määrittelee virhesivut.
Esimerkiksi:
<servlet>
<servlet-name>MyServlet</servlet-name>
<servlet-class>com.example.MyServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>MyServlet</servlet-name>
<url-pattern>/path</url-pattern>
</servlet-mapping>
Tämä käskee säilön käsittelemään pyyntöjä /path käyttämällä MyServlet.
7) Mitä ovat servlettien alustusparametrit?
Servletit vaativat usein konfigurointitietoja (kuten tietokannan yhteysmerkkijonoja). Nämä voidaan tarjota seuraavien kautta: init-parametrit joko web.xml tai käyttämällä merkintöjä, kuten @WebInitParam.
Voit hankkia nämä parametrit käyttämällä:
ServletConfig config = getServletConfig();
String paramValue = config.getInitParameter("paramName");
Tämä mahdollistaa servletin toiminnan mukauttamisen ilman koodin uudelleenkääntämistä.
8) Servlet-istuntojen hallinnan esittely
HTTP on luonnostaan tilaton. istuntojen hallinta mahdollistaa tilan ylläpitämisen useiden pyyntöjen aikana. Yleisiä tekniikoita ovat:
- Evästeet – Pieniä tietoja, jotka tallennetaan asiakasselaimeen ja lähetetään jokaisen pyynnön mukana.
- URL-osoitteen uudelleenkirjoitus – Istuntotunnusten lisääminen URL-osoitteisiin, kun evästeet on poistettu käytöstä.
- HTTPSession-API – Sisäänrakennettu istunnonhallinta
HttpSessionesine.
Esimerkiksi:
HttpSession session = request.getSession();
session.setAttribute("user", userObject);
Tämä luo asiakkaaseen sidotun istunto-objektin.
9) Mitä on URL-koodaus vs. URL-uudelleenkirjoittaminen?
Molemmat ovat istunnonhallintatekniikoita:
- URL-koodaus muokkaa URL-osoitteita sisältämään erikoismerkkejä turvallista siirtoa varten.
- URL-osoitteen uudelleenkirjoitus liittää istuntotunnuksen URL-osoitteeseen, kun evästeitä ei ole käytettävissä.
Esimerkiksi:
response.encodeURL("dashboard");
Tämä varmistaa istunnon seurannan, vaikka evästeet olisi poistettu käytöstä.
10) Onko Servlet säikeiden kannalta turvallinen? Miten säikeiden turvallisuus saavutetaan?
Oletusarvoisesti servlet-instanssit käsittelevät useita pyyntöjä säikeiden avulla. Siksi servletit eivät ole luonnostaan säikeeturvallisia ellei sitä ole suunniteltu huolella.
Strategioita lankojen turvallisuuden varmistamiseksi:
- Vältä instanssimuuttujien käyttöä ilman synkronointia.
- Käytä paikallisia muuttujia pyyntömetodien sisällä.
- Synckronikoi pääsy jaettuihin resursseihin tarvittaessa.
Esimerkiksi:
public void doGet(...) {
int localVar = computeValue();
}
Paikallisten muuttujien käyttö välttää jaettujen tilojen ongelmat.
11) Mikä on Servlet-suodatin ja sen käyttötapaukset?
A Servlet-suodatin sieppaa pyynnöt ennen kuin ne saavuttavat servletin (tai vastaukset ennen kuin ne saavuttavat asiakkaan). Suodattimet käsittelevät tehtäviä, kuten:
- Authentication
- Hakkuu
- Puristus
- Syötteen vahvistus
Esimerkiksi: Käytä suodatinta tarkistaaksesi, onko pyyntö todennettu, ennen kuin lähetät sen edelleen suojatuille sivuille.
12) Mitä ovat Servlet-kuuntelijat?
kuuntelijoita ovat tapahtumankäsittelijöitä, jotka reagoivat verkkosovelluksen elinkaaritapahtumiin. Yleisiä kuuntelijarajapintoja ovat:
ServletContextListener— Sovelluksen käynnistys-/sammutustapahtumat.HttpSessionListener— Istunnon luominen ja tuhoaminen.ServletRequestListener— Pyyntöjen elinkaaritapahtumat.
Kuuntelijat auttavat resurssien allokoinnin tai siivoamisen hallinnassa sovelluksen toiminnan perusteella.
13) Miten pyyntö välitetään toiselle resurssille?
Pyynnön välittäminen sisäisesti:
RequestDispatcher rd = request.getRequestDispatcher("/otherServlet");
rd.forward(request, response);
Uudelle URL-osoitteelle uudelleenohjaaminen:
response.sendRedirect("newURL");
Ero:
forward()käsitellään sisäisesti ilman asiakkaan uudelleenohjausta.sendRedirect()kehottaa asiakasta tekemään uuden pyynnön.
14) Selitä ServletContext ja ServletConfig
| Ominaisuus | ServletContext |
ServletConfig |
|---|---|---|
| Laajuus | Sovelluksenlaajuinen | Yhdelle servletille ominainen |
| Käytetty | Jaetut resurssit, globaalit alustusparametrit | Yksittäiset servletin alustusparametrit |
| Elinikäinen | Kunnes sovellus puretaan | Kunnes servlet tuhoutuu |
ServletContext tarjoaa jaettua dataa kaikille web-sovelluksen servletteille samalla kun ServletConfig on sidoksissa yhteen servlet-instanssiin.
15) Mikä on HttpSession ja miten sitä käytetään?
HttpSession objekti edustaa käyttäjäistuntoa useiden HTTP-pyyntöjen ja -vastausten aikana. Se tarjoaa etuja, kuten:
- Käyttäjäkohtaisten tietojen tallentaminen
- Istunnon aikakatkaisun hallinta
- Kirjautumisen tilan seuranta
Esimerkiksi:
HttpSession session = request.getSession(true);
session.setAttribute("cart", shoppingCart);
Tämä säilyttää tiedot pyyntöjen välillä.
16) Miten lataat tiedoston palvelimelle Servletin avulla?
Tiedoston lataaminen:
- Configure
<multipart-config>inweb.xml. - Käyttää
ServletFileUploadtai servlet 3.0 -annotaatioita. - Käsittele tiedoston osat kohdassa
doPost().
Tämä skenaario on yleinen todellisissa sovelluksissa, kuten profiilikuvien latauksissa.
17) Selitä, miten poikkeuksia käsitellään servletissä
Servletit voivat käsitellä poikkeuksia kahdella tavalla:
- Try-catch-lohkot servlet-koodissa.
- Määritellä
<error-page>inweb.xmlpoikkeusten yhdistämiseksi mukautettuihin virheenkorjaussivuihin.
Esimerkiksi:
<error-page> <exception-type>java.lang.Exception</exception-type>
<location>/error.jsp</location>
</error-page>
Tämä parantaa luotettavuutta ja käyttäjäkokemusta.
18) Mikä on annotaatioiden rooli Servleteissä (Servlet 3.0+)?
Servlet 3.0:sta lähtien merkinnät voivat korvata web.xml:
@WebServlet("/path")@WebFilter@WebListener
Esimerkiksi:
@WebServlet("/hello")
public class HelloServlet extends HttpServlet { ... }
Tämä yksinkertaistaa konfigurointia ja käyttöönottoa.
19) Mikä on käynnistyksen yhteydessä tapahtuva lataus?
<load-on-startup> in web.xml ohjaa servletin alustusta:
- Positiivinen arvo → ladataan sovelluksen käynnistyksen yhteydessä määritellyssä järjestyksessä.
- Negatiivinen tai puuttuu → kuormitus ensimmäisellä pyynnöllä.
Esimerkiksi:
<load-on-startup>1</load-on-startup>
Tämä varmistaa, että servlet on valmis ennen pyyntöjen saapumista.
20) Miten servletit tukevat RESTful-palveluita?
Servletit voivat toteuttaa RESTin käsittelemällä erilaisia HTTP-verbejä (GET, POST, PUT, DELETE) pyyntömetodeissa ja tuottamalla JSON/XML-vastauksia käyttämällä PrintWriter tai virtoja. Tyypillinen REST-päätepiste validoi URL-osoitteet ja on vuorovaikutuksessa liiketoimintalogiikan kanssa sen mukaisesti.
21) Selitä sendRedirect():n ja forward():n välinen ero Servleteissä.
Ero sendRedirect() ja forward() piilee miten pyyntöjen hallinta siirretään ja missä uudelleenohjaus tapahtuuMolempia mekanismeja käytetään käyttäjien navigointiin resurssien välillä, mutta niillä on erilaiset arkkitehtuurilliset tarkoitukset.
sendRedirect() on asiakaspuolen uudelleenohjausServlet käskee selainta lähettämään uuden HTTP-pyynnön eri URL-osoitteeseen. Tämän seurauksena selaimen osoiterivi muuttuu ja pyyntöattribuutit menetetään. Tämä lähestymistapa on hyödyllinen ohjattaessa ulkoisiin resursseihin tai vältettävässä lomakkeen uudelleenlähetysongelmissa.
forward() on palvelinpuolen toiminta säiliön käsittelemä käyttämällä RequestDispatcherSamat pyyntö- ja vastausobjektit välitetään sisäisesti, mikä säilyttää pyyntöattribuutit ja parantaa suorituskykyä.
| Aspect | sendRedirect() | eteenpäin() |
|---|---|---|
| Uudelleenohjauksen tyyppi | Asiakkaan puolella | Palvelimen puolella |
| URL-osoitteen muutos | Kyllä | Ei |
| Pyyntöobjekti | Uusi | Sama |
| Suorituskyky | hitaampi | Nopeampi |
22) Mitä erilaisia Servlet-istuntojen seurantamekanismeja on olemassa?
Servlettien tuki useita istunnon seurantamekanismeja hallita käyttäjän tilaa luonnostaan tilattomassa HTTP-protokollassa. Valinta riippuu selaimen yhteensopivuudesta, tietoturvavaatimuksista ja skaalautuvuustarpeista.
Yleisin lähestymistapa on Evästeet, jossa istuntotunnisteet tallennetaan asiakkaalle ja lähetetään jokaisen pyynnön mukana. Evästeet ovat tehokkaita, mutta käyttäjät voivat poistaa ne käytöstä.
URL-osoitteen uudelleenkirjoitus liittää istuntotunnukset URL-osoitteisiin ja on hyödyllinen, kun evästeet eivät ole käytettävissä, vaikka se paljastaa istuntotiedot selainhistoriassa.
Piilotetut lomakekentät upottaa istuntotietoja HTML-lomakkeisiin, mutta tämä menetelmä toimii vain lomakepohjaisessa navigoinnissa.
Kestävin ratkaisu on HttpSession, joka tiivistää nämä mekanismit ja sallii kehittäjien tallentaa istuntotietoja palvelinpuolella.
| Menetelmä | edut | Haitat |
|---|---|---|
| Evästeet | Tehokas, läpinäkyvä | Voidaan poistaa käytöstä |
| URL-osoitteen uudelleenkirjoitus | Toimii ilman evästeitä | Turvallisuusriski |
| Piilotetut kentät | Yksinkertainen | Rajoitettu navigointi |
| HttpSession | Turvallinen, joustava | Palvelimen muistin käyttö |
23) Miten HttpSession-elinkaari toimii Servleteissä?
HttpSession Elinkaari alkaa, kun asiakas tekee ensimmäisen pyynnön, joka vaatii istunnon seurantaa. Servlettisäiliö luo istunto-objektin ja antaa sille yksilöllisen istunto-ID:n. Tämä ID tallennetaan yleensä evästeeseen nimeltä JSESSIONID.
Istunto pysyy aktiivisena niin kauan kuin pyynnöt jatkuvat määritetyn aikakatkaisuajan sisällä. Kehittäjät voivat hallita tätä käyttämällä setMaxInactiveInterval() or web.xml kokoonpano. Istunnot voivat päättyä aikakatkaisun tai nimenomaisen mitätöinnin vuoksi käyttämällä invalidate()tai sovelluksen sammuttaminen.
Tärkeä elinkaaritapahtuma tapahtuu, kun istuntoja luodaan tai tuhotaan, ja niitä voidaan seurata käyttämällä HttpSessionListenerTämä on hyödyllistä auditointia tai resurssien siivousta varten.
Esimerkiksi: Kirjautuneiden käyttäjien seuranta lisäämällä laskuria istuntojen luomisen yhteydessä ja vähentämällä sitä tuhoutumisen yhteydessä varmistaa tarkat samanaikaisuusmittarit.
24) Mikä on ServletContextin rooli web-sovelluksessa?
ServletContext edustaa koko verkkosovellus ja tarjoaa jaetun viestintämekanismin kaikkien servlettien, suodattimien ja kuuntelijoiden välillä. Se luodaan kerran sovelluksen käynnistyksen yhteydessä ja tuhotaan sammutuksen yhteydessä.
Kehittäjät käyttävät ServletContext tallentaa globaaleja määritteitä, lukea sovelluskohtaisia alustusparametreja ja käyttää resursseja, kuten määritystiedostoja. Toisin kuin HttpSession, se ei ole käyttäjäkohtainen.
Esimerkiksi käynnistyksen yhteydessä alustettu tietokantayhteyspooli voidaan tallentaa ServletContext ja käyttää uudelleen useissa servletteissä, mikä parantaa suorituskykyä ja vähentää resurssien ylimääräistä käyttöä.
| Ominaisuus | Servlet-konteksti |
|---|---|
| Laajuus | Sovelluksenlaajuinen |
| Elinikäinen | Koko hakemus |
| Jaettu data | Kyllä |
| Käyttäjäkohtainen | Ei |
25) Miten Servlet-suodattimet toimivat ja mitkä ovat niiden edut?
Servlet-suodattimet toimivat sieppaajat jotka käsittelevät pyyntöjä ja vastauksia ennen servletin suoritusta tai sen jälkeen. Niitä käytetään yleisesti laaja-alaisiin kysymyksiin, joita ei tulisi upottaa liiketoimintalogiikkaan.
Suodattimet sopivat erinomaisesti todennukseen, valtuutukseen, lokinnukseen, pakkaamiseen ja pyyntöjen validointiin. Ne voivat muokata pyyntöparametreja, otsikoita tai jopa estää pääsyn ennen servletin saavuttamista.
Useita suodattimia voidaan ketjuttaa yhteen muodostaen käsittelyputken. Tämä edistää modulaarisuutta ja huolenaiheiden eriyttämistä.
Esimerkiksi: Todennussuodatin tarkistaa käyttäjän tunnistetiedot ennen suojattujen resurssien käytön sallimista varmistaen yhdenmukaisen tietoturvan valvonnan koko sovelluksessa.
26) Selitä Servlet-säikeistysmalli ja samanaikaisuuden käsittely
Servletit seuraavat monisäikeinen suoritusmalli jossa yksi servlet-instanssi käsittelee useita pyyntöjä samanaikaisesti erillisten säikeiden avulla. Vaikka tämä parantaa skaalautuvuutta, se tuo mukanaan samanaikaisuusriskejä.
Instanssimuuttujat jaetaan säikeiden kesken, mikä tekee servleteistä luonnostaan ei säikeille sopivaRinnakkaisuuden hallitsemiseksi kehittäjien tulisi käyttää paikallisia muuttujia, muuttumattomia objekteja tai synkronoituja lohkoja käyttäessään jaettuja resursseja.
Synkronoinnin käyttäminen harkitsemattomasti voi heikentää suorituskykyä, joten säikeiden turvallisuus on saavutettava huolellisella suunnittelulla eikä liiallisella lukituksella.
Esimerkiksi: Jaettua laskuria käyttävän servletin tulisi synkronoida päivitykset tai käyttää atomisia muuttujia kilpailutilanteiden estämiseksi.
27) Mitä eroa on GET- ja POST-metodeilla Servleteissä?
GET ja POST ovat yleisimmin käytetyt HTTP-menetelmät Servleteissä, mutta niillä on eri tarkoitukset.
GET on suunniteltu tietojen haku ja lisää parametreja URL-osoitteeseen. Se on välimuistissa ja kirjanmerkeissä, mutta paljastaa arkaluonteisia tietoja.
POST on tarkoitettu tietojen toimittaminen ja lähettää parametrit pyynnön rungossa. Se on turvallisempi ja sopii operaatioille, jotka muokkaavat palvelimen tilaa.
| Aspect | SAA | POST |
|---|---|---|
| Tietojen näkyvyys | URL | Pyynnön runko |
| Turvallisuus | Matala | Korkeammat |
| Idempotentti | Kyllä | Ei |
| Käytä asiaa | Hae tiedot | Lähetä tiedot |
28) Miten poikkeuksia käsitellään Servlet-pohjaisissa sovelluksissa?
Servlettien poikkeusten käsittelyä voidaan hallita ohjelmallisesti tai deklaratiivisesti. Ohjelmallinen käsittely käyttää try-catch-lohkoja ajonaikaisten ongelmien tallentamiseen ja käsittelyyn suoraan koodissa.
Deklaratiivisen käsittelyn vipuvaikutukset web.xml poikkeusten tai HTTP-tilakoodien yhdistämiseksi mukautettuihin virhesivuihin. Tämä lähestymistapa parantaa ylläpidettävyyttä ja käyttökokemusta erottamalla virhelogiikan liiketoimintalogiikasta.
Esimerkiksi: Kartoitus NullPointerException virheeseen liittyvä JSP mahdollistaa yhdenmukaisen virheraportoinnin koko sovelluksessa ilman toistuvaa koodia.
Tämä kerrostettu lähestymistapa varmistaa kestävyyden ja puhtaamman arkkitehtuurin.
29) Mitä on käynnistyksen yhteydessä tapahtuva lataus ja milloin sitä tulisi käyttää?
load-on-startup määrittää kun servlet alustetaan säilön toimesta. Positiivinen kokonaislukuarvo ohjeistaa säilöä lataamaan servletin sovelluksen käynnistyksen aikana, kun taas poissaolo tai negatiiviset arvot viivästyttävät latausta ensimmäiseen pyyntöön asti.
Tämä ominaisuus on hyödyllinen servleteille, jotka suorittavat kriittisiä alustustehtäviä, kuten määritystiedostojen lataamista, välimuistien alustamista tai tietokantayhteyksien määrittämistä.
Käyttäminen load-on-startup varmistaa, että nämä tehtävät suoritetaan ennen kuin sovellus alkaa palvella pyyntöjä, mikä parantaa luotettavuutta.
30) Miten Servletit tukevat RESTful-verkkopalveluita?
Servletit muodostavat RESTful-palveluiden perustan käsittelemällä erilaisia HTTP-metodeja, kuten GET, POST, PUT ja DELETE. Jokainen metodi vastaa CRUD-operaatiota ja se toteutetaan käyttämällä doGet(), doPost()ja niihin liittyvät käsittelijät.
Palauttamalla JSON- tai XML-vastauksia ja noudattamalla REST-periaatteita, kuten tilattomuutta ja resurssipohjaisia URL-osoitteita, Servletit voivat toteuttaa kevyitä API-rajapintoja.
Nykyaikaiset kehykset abstraktoivat tämän monimutkaisuuden, mutta RESTful Servlet -suunnittelun ymmärtäminen on kriittistä matalan tason ohjauksen ja suorituskyvyn hienosäädön kannalta, erityisesti työskenneltäessä suoraan Jakartan servletti API.
31) Mitä erilaisia Servlet-laajuustyyppejä on olemassa ja miten niitä käytetään?
Servlettien laajuusalueet määrittelevät ominaisuuksien näkyvyys ja elinikä verkkosovellukseen tallennettuna. Ne ovat välttämättömiä komponenttien välisen tiedonjaon hallitsemiseksi ja samalla asianmukaisen eristämisen ylläpitämiseksi.
Neljä ensisijaista laajuusaluetta ovat Pyydä, istunto, Hakemusja Sivu (käytetään pääasiassa JSP:ssä). Pyynnön laajuus kestää yhden HTTP-pyynnön ja sopii erinomaisesti väliaikaisen tiedon välittämiseen servletien tai JSP:iden välillä. Istuntolaajuus säilyy useiden saman asiakkaan pyyntöjen välillä ja sitä käytetään yleisesti käyttäjäkohtaisiin tietoihin, kuten kirjautumistilaan. Sovelluksen laajuus on globaali ja jaettu kaikkien käyttäjien kesken, joten se sopii konfigurointiin tai jaettuihin resursseihin.
Laajuusvalinnan ymmärtäminen estää muistivuotoja ja samanaikaisuusongelmia.
| Laajuus | Elinikäinen | Näkyvyys | Tyypillinen käyttö |
|---|---|---|---|
| Pyydä | Yksittäinen pyyntö | Sama pyyntö | Vahvistusviestit |
| istunto | Käyttäjäistunto | yhdelle käyttäjälle | Kirjautumistiedot |
| Hakemus | Sovelluksen elinkaari | Kaikki käyttäjät | Välimuistit, konfiguroinnit |
| Sivu | Vain JSP | Sama JSP | Näytä logiikka |
32) Miten Servlet-tietoturva toimii käyttöönottodeskriptorien avulla?
Servlettien suojaus voidaan määrittää deklaratiivisesti käyttämällä web.xml ilman sovelluskoodin muokkaamista. Tämä lähestymistapa parantaa ylläpidettävyyttä ja valvoo yhdenmukaisia tietoturvasääntöjä.
Tietoturvarajoitukset määrittelevät suojatut URL-mallit ja sallitut HTTP-menetelmät. Todennusmenetelmät, kuten BASIC, FORM tai CLIENT-CERT, määrittävät, miten käyttäjät todennetaan. Roolipohjainen todennus rajoittaa käyttöoikeuksia käyttäjäroolien perusteella.
Esimerkiksi vain järjestelmänvalvojille tarkoitettu osio voidaan suojata siten, että vain ADMIN-roolilla varustetut käyttäjät voivat käyttää sitä. Tämä mekanismi integroituu saumattomasti säilöpohjaiseen suojaukseen.
Deklaratiivista tietoturvaa suositaan yrityssovelluksissa, koska se erottaa tietoturvalogiikan liiketoimintalogiikasta ja tukee standardoitua valvontaa.
33) Selitä tilattomien ja tilallisten servlettien välinen ero.
Tilattomat ja tilalliset servletit eroavat toisistaan siinä, miten ne hallitsevat asiakaskohtaista dataa.
A tilaton servlet ei tallenna asiakkaan tilaa pyyntöjen välillä. Jokainen pyyntö on itsenäinen, mikä tekee servletistä erittäin skaalautuvan ja sopivan RESTful-palveluille.
A tilallinen servlettoisaalta ylläpitää tilaa istuntojen, evästeiden tai instanssimuuttujien avulla. Tämä lähestymistapa on hyödyllinen työnkuluissa, kuten ostoskoreissa tai monivaiheisissa lomakkeissa.
| Aspect | kansalaisuudeton | Tilallinen |
|---|---|---|
| skaalautuvuus | Korkea | Laske |
| Muistin käyttö | Vähimmäismäärä | Korkeammat |
| Käytä asiaa | APIt, mikropalvelut | Käyttäjän työnkulut |
| Monimutkaisuus | Matala | Korkeammat |
Nykyaikaiset arkkitehtuurit suosivat tilattomia servlettejä pilvipalveluiden skaalautuvuusvaatimusten vuoksi.
34) Mikä on RequestDispatcher ja miten se eroaa uudelleenohjauksesta?
RequestDispatcher mahdollistaa sisäinen viestintä palvelinpuolen resurssien välillä kuten servlettejä ja JSP:itä. Se mahdollistaa sisällön edelleenlähettämisen tai sisällyttämisen ilman asiakkaan osallistumista.
Keskeinen etu on, että samoja pyyntö- ja vastausobjekteja käytetään uudelleen, mikä parantaa suorituskykyä ja säilyttää pyyntöattribuutit. Tämä on ihanteellista MVC-arkkitehtuureille, joissa ohjainservlet välittää tiedot näkymään.
Uudelleenohjaus sitä vastoin vaatii asiakkaalta uuden pyynnön, joka on hitaampi eikä säilytä pyyntötietoja. Valinta näiden kahden välillä riippuu siitä, tarvitaanko asiakkaan tietoisuutta ja URL-osoitteiden muutoksia.
35) Mitä ovat Servlet-annotaatiot ja mitä etuja ne tarjoavat?
Servlet-annotaatiot otettiin käyttöön XML-konfiguraatiokustannusten vähentämiseksi ja kehityksen yksinkertaistamiseksi. Annotaatiot, kuten @WebServlet, @WebFilterja @WebListener sallia kehittäjien ilmoittaa metatiedot suoraan koodissa.
Ensisijaisia etuja ovat parantunut luettavuus, vähentyneet konfigurointivirheet ja nopeammat kehityssyklit. Annotaatiot myös helpottavat sovellusten uudelleenjärjestelyä, koska konfigurointi ja toteutus pysyvät tiiviisti linjassa keskenään.
Suurten yritysten sovelluksissa käytetään kuitenkin usein hybridimenetelmää, jossa merkinnät käsittelevät yksinkertaisia määrityksiä ja web.xml hallitsee monimutkaisia kokoonpanoja.
36) Miten Servletin suorituskyvyn viritys toimii?
Servlettien suorituskyvyn virittäminen tarkoittaa optimointia resurssien käyttö, samanaikaisuuden käsittely ja vasteaikaYleisiä strategioita ovat synkronoinnin minimointi, objektien uudelleenkäyttö yhdistämisen avulla ja vastausten pakkaamisen mahdollistaminen.
Yhteyspoolien käyttäminen pyyntökohtaisten tietokantayhteyksien luomisen sijaan parantaa merkittävästi läpimenoaikaa. Usein käytettyjen tietojen välimuistiin tallentaminen sovelluksen laajuudessa vähentää tarpeetonta laskentaa.
Myös servlet-kontin säikeiden koko on ratkaisevan tärkeä. Huono säätö voi johtaa säikeiden puutteeseen tai liialliseen kontekstin vaihtamiseen.
Suorituskyvyn viritys on jatkuva prosessi, joka vaatii seurantaa, profilointia ja iteratiivista optimointia.
37) Mitä eroja on Servleteillä ja JSP:llä?
Servleteillä ja JSP:llä on eri roolit Java verkkosovellukset, vaikka molemmat lopulta kääntyvät servleteiksi.
Servletit ovat Java kurssit, jotka keskittyvät pyyntöjen käsittelyyn ja liiketoimintalogiikkaan. JSP:t on suunniteltu esittelyä varten ja ne yksinkertaistavat HTML:n luomista tagien ja lausekekielen avulla.
| Aspect | Servlet | JSP |
|---|---|---|
| Rooli | Ohjain/Logiikka | Näytä |
| Syntaksi | Java | HTML + tagit |
| Huolto | Runsassanaisempi | Helpompi |
| MVC-käyttö | ohjain | Näytä |
Parhaiden käytäntöjen mukaan Servlettejä käytetään ohjaimina ja JSP:itä yksinomaan näkymien renderöintiin.
38) Miten Servlet käsittelee tiedostojen lataukset?
Tiedostojen lataukset käsitellään moniosaisten pyyntöjen avulla. Servlet-määritykset tarjoavat sisäänrakennetun tuen moniosaiselle käsittelylle merkintöjen tai konfiguroinnin avulla.
Servlet lukee ladatun tiedoston tiedot muodossa Part objekteja, mikä mahdollistaa pääsyn tiedostojen metatietoihin ja sisältövirtoihin. Ladatut tiedostot voidaan sitten validoida, tallentaa tai käsitellä edelleen.
Tiedostojen latauksen asianmukainen käsittely sisältää kokorajoitukset, tyypin validoinnin ja turvallisen tallennuksen haavoittuvuuksien, kuten haitallisen tiedostojen suorittamisen, estämiseksi.
Tätä ominaisuutta käytetään yleisesti profiilinhallintajärjestelmissä, asiakirjojen latauksissa ja sisällönhallintajärjestelmissä.
39) Mitä on asynkroninen prosessointi Servleteissä?
Asynkroninen käsittely mahdollistaa servletin käsitellä pitkään suoritettavia tehtäviä estämättä pyyntöjen käsittelysäiettä. Tämä parantaa skaalautuvuutta ja reagointikykyä raskaan kuormituksen aikana.
Asynkronisten API-rajapintojen avulla servlet vapauttaa säilöketjun ja käsittelee pyynnön taustalla. Kun käsittely on valmis, vastausta jatketaan.
Tämä malli sopii erinomaisesti esimerkiksi ulkoisiin API-kutsuihin, eräkäsittelyyn tai datan suoratoistoon.
Asynkroniset servlettit parantavat merkittävästi läpimenoaikaa korkean samanaikaisuuden ympäristöissä, kun niitä käytetään oikein.
40) Mitä yleisiä Servlet-parhaita käytäntöjä noudatetaan yrityssovelluksissa?
Yritystason servlettien kehitys noudattaa tiukkoja parhaita käytäntöjä ylläpidettävyyden, skaalautuvuuden ja turvallisuuden varmistamiseksi. Näihin kuuluvat liiketoimintalogiikan välttäminen servletteissä, MVC-arkkitehtuurin käyttö, konfiguraation ulkoistaminen ja säikeiden turvallisuuden varmistaminen.
Muita käytäntöjä ovat asianmukainen poikkeusten käsittely, turvallinen istunnonhallinta ja instanssimuuttujien minimaalinen käyttö. Lokikirjaus ja valvonta tulisi toteuttaa johdonmukaisesti.
Näiden periaatteiden noudattaminen johtaa puhtaisiin, testattaviin ja tuotantovalmiisiin sovelluksiin, jotka toimivat luotettavasti kuormituksen alla.
🔍 Tärkeimmät Servlet-haastattelukysymykset tosielämän skenaarioilla ja strategisilla vastauksilla
1) Mikä on Servlet ja miksi sitä käytetään web-sovelluksissa?
Ehdokkaalta odotetaan: Haastattelija haluaa arvioida perustavanlaatuista ymmärrystäsi servleteistä ja niiden roolista Java-pohjaisia verkkosovelluksia.
Esimerkki vastauksesta: Servlet on Java luokka, joka toimii web-palvelimella ja käsittelee asiakaspyyntöjä, yleensä HTTP:n kautta. Sitä käytetään dynaamisten web-sovellusten rakentamiseen käsittelemällä pyyntöjä, soveltamalla liiketoimintalogiikkaa ja luomalla vastauksia. Servlettejä suositaan, koska ne ovat alustariippumattomia, tehokkaita monisäikeisyyden ansiosta ja tiiviisti integroituja Java yritysteknologiat.
2) Voitko selittää Servletin elinkaaren?
Ehdokkaalta odotetaan: Haastattelija testaa tietosi siitä, miten säilö hallitsee Servletiä.
Esimerkki vastauksesta: Servletin elinkaari koostuu kolmesta päävaiheesta: alustus, pyynnön käsittely ja tuhoaminen. Kontti kutsuu ensin init() menetelmä Servletin alustamiseksi. Sitten se kutsuu service() menetelmä asiakaspyyntöjen käsittelemiseksi, jotka voivat delegoida doGet() or doPost()Lopuksi, kun Servlet poistetaan käytöstä, destroy() metodia kutsutaan resurssien vapauttamiseksi.
3) Miten käsittelet asiakaspyyntöjä Servletissä?
Ehdokkaalta odotetaan: He haluavat ymmärtää, miten työskentelet HTTP-metodien ja pyyntöjen käsittelyn kanssa.
Esimerkki vastauksesta: Asiakaspyynnöt käsitellään palvelun kautta service() metodi, joka reitittää pyynnöt tietyille metodeille, kuten doGet(), doPost(), doPut()tai doDelete() HTTP-metodiin perustuen. Jokainen metodi käsittelee pyynnön, on tarvittaessa vuorovaikutuksessa taustajärjestelmän komponenttien kanssa ja kirjoittaa vastauksen käyttämällä HttpServletResponse esine.
4) Miten istunnon seurantaa hallitaan Servleteissä?
Ehdokkaalta odotetaan: Haastattelija haluaa tietää, miten ylläpidät käyttäjän tilaa useiden pyyntöjen aikana.
Esimerkki vastauksesta: Servlettien istuntojen seurantaa voidaan hallita käyttämällä HttpSession, evästeitä, URL-osoitteiden uudelleenkirjoittamista tai piilotettuja lomakekenttiä. Yleisin lähestymistapa on käyttää HttpSession, jonka avulla käyttäjäkohtaisia tietoja voidaan tallentaa palvelimelle ja hakea useiden pyyntöjen kautta, kunnes istunto vanhenee tai mitätöidään.
5) Kuvaile tilannetta, jossa optimoit Servlet-pohjaisen sovelluksen suorituskyvyn.
Ehdokkaalta odotetaan: He arvioivat ongelmanratkaisutaitojasi ja käytännön kokemustasi.
Esimerkki vastauksesta: Edellisessä roolissani optimoin Servlet-pohjaista sovellusta vähentämällä tarpeettomia tietokantakutsuja ja ottamalla käyttöön yhteyspoolin. Minimoin myös objektien luomisen palvelimen sisällä. doGet() menetelmää ja mahdollisti usein käytettyjen tietojen välimuistin tallennuksen. Nämä muutokset paransivat merkittävästi vasteaikaa ja palvelimen suorituskykyä.
6) Miten käsittelet poikkeuksia Servleteissä?
Ehdokkaalta odotetaan: Haastattelija etsii strukturoituja virheidenkäsittelykäytäntöjä.
Esimerkki vastauksesta: Servlet-koodin poikkeukset voidaan käsitellä käyttämällä try-catch-lohkoja tai määrittelemällä virhesivuja web.xml tai merkintöjen kautta. Pidän parempana keskitettyä virheiden käsittelyä, jossa poikkeukset kirjataan oikein ja käyttäjille palautetaan merkitykselliset virhevastaukset paljastamatta sisäisiä tietoja.
7) Mitä eroa on RequestDispatcher forwardin ja sendRedirectin välillä?
Ehdokkaalta odotetaan: He haluavat testata ymmärrystäsi pyyntöjen kulusta ja navigoinnista.
Esimerkki vastauksesta: RequestDispatcher siirtää ohjauksen eteenpäin palvelimen toiselle resurssille muuttamatta URL-osoitetta, ja käytetään samoja pyyntö- ja vastausobjekteja. Sitä vastoin sendRedirect lähettää asiakkaalle vastauksen, jossa se kehottaa sitä tekemään uuden pyynnön eri URL-osoitteeseen, mikä johtaa URL-osoitteen muutokseen ja uuteen pyyntö-vastaus-sykliin.
8) Kerro minulle tilanteesta, jossa työskentelit suodattimien tai kuuntelijoiden kanssa Servlet-pohjaisessa projektissa.
Ehdokkaalta odotetaan: Haastattelija haluaa tietää kokemuksistasi Servletin edistyneiden ominaisuuksien kanssa.
Esimerkki vastauksesta: Edellisessä työssäni käytin Servlet-suodattimia lokitietojen ja todennustarkistusten toteuttamiseen ennen kuin pyynnöt saapuivat ydin-Servleteille. Työskentelin myös kuuntelijoiden kanssa istuntojen luomis- ja tuhoamistapahtumien seuraamiseksi, mikä auttoi aktiivisten käyttäjien valvonnassa ja resurssien tehokkaassa siivoamisessa.
9) Miten käsittelisit suuren liikenteen tilannetta Servlet-sovelluksessa?
Ehdokkaalta odotetaan: He testaavat kykyäsi suunnitella skaalautuvia ja luotettavia järjestelmiä.
Esimerkki vastauksesta: Varmistaisin tehokkaan monisäikeisyyden pitämällä Servletit tilattomina aina kun mahdollista ja käyttämällä säikeenkestävästi toimivia komponentteja. Edellisessä työssäni käytin myös kuormituksen tasapainotusta, välimuistimekanismeja ja optimoitua tietokannan käyttöä käsitelläkseni suurta liikennettä suorituskyvyn heikentymättä.
10) Kuvaile haastavaa ongelmaa, jonka kohtasit Servletin debugatessa ja miten ratkaisit sen.
Ehdokkaalta odotetaan: Haastattelija haluaa arvioida virheenkorjaustapaasi ja joustavuuttasi.
Esimerkki vastauksesta: Edellisessä roolissani kohtasin ongelman, jossa Servlet palautti ajoittain virheellisiä vastauksia säikeiden välisen jaetun muokattavan datan vuoksi. Ratkaisin ongelman tunnistamalla säikeiden turvallisuusongelman, refaktoroimalla koodin poistaakseen jaetun tilan ja lisäämällä asianmukaisen lokikirjauksen korjauksen varmistamiseksi samanaikaisen kuormituksen aikana.
