Utforske spørsmål og svar fra et jobbintervju for en Java-utviklerstilling. Del 1

Hei! CodeGym har samlet en mangfoldig gruppe mennesker. Noen av oss ønsker ikke noe annet enn å bli Java-utviklere, og vi investerer mye tid og krefter på utvikling. Andre er allerede Java-utviklere. I begge tilfeller må du være klar til å bli testet i tekniske intervjuer. Disse er ikke enkle. De krever både emosjonell og teknisk forberedelse. Jeg kom nylig over noen store lister med intervjuspørsmål for Java-utviklerstillinger. Spørsmålene er delt inn i ulike nivåer: junior, mellomnivå og senior. Ikke bli skremt: ikke alle spørsmålene er enkle, men de med en stjerne blir sjelden stilt. Spørsmålene er gode, og jeg vil gjerne prøve å svare på de fleste. Det er klart at alt dette ikke passer i en enkelt artikkel. Det er tross alt mange spørsmål der. Det betyr at det kommer en hel serie artikler med svar på disse intervjuspørsmålene. La meg understreke noen punkter med en gang: svarene vil være korte, fordi svar skrevet i stor detalj kan trekkes ut i en egen artikkel. Ved intervjuer er det heller ikke ønskelig med superdetaljerte og omfangsrike svar, fordi intervjueren din bare har en time på seg til å intervjue deg om viktige emner (og,

Spørsmål og svar for en juniorutviklerstilling

Generelle spørsmål

1. Hvilke designmønstre kjenner du til? Fortell oss om to designmønstre du har brukt i arbeidet ditt.

Det er et stort utvalg av mønstre. For de av dere som ønsker å sette dere grundig inn i designmønstre, anbefaler jeg å lese boken "Head First. Design Patterns". Det vil hjelpe deg enkelt å lære detaljene i de mest grunnleggende designmønstrene. Når det gjelder designmønstre som du kan nevne i et jobbintervju, kommer følgende til tankene:

• Builder — en ofte brukt mal, et alternativ til den klassiske tilnærmingen til objektskaping;
• Strategi - et mønster som i hovedsak representerer polymorfisme. Det vil si at vi har ett grensesnitt, men programmets virkemåte endres avhengig av den spesifikke grensesnittimplementeringen som sendes til funksjonen (strategimønsteret brukes nå omtrent overalt i Java-applikasjoner).

Hvis det ikke er nok for deg, vær oppmerksom på Spring (hvis du allerede er kjent med det), fordi det er en hel plattform av rammer, som igjen er gjennomsyret av mønstre fra begynnelse til slutt. Her er et par eksempler på hva jeg snakker om:

• Factory — dette mønsteret kan bli funnet i ApplicationContext (eller i BeanFactory);
• Singleton - alle bønner er singletons som standard;
• Proxy — i utgangspunktet bruker alt i Spring dette mønsteret på en eller annen måte, for eksempel AOP;
• Ansvarskjede - et mønster som underbygger Spring Security;
• Mal — brukt i Spring JDBC.

Java kjerne

2. Hvilke datatyper finnes i Java?

Java har følgende primitive datatyper:

• byte — heltall fra -128 til 127, tar opp 1 byte;
• kort — heltall fra -32768 til 32767, tar opp 2 byte;
• int — heltall fra -2147483648 til 2147483647, tar opp 4 byte;
• lang — heltall fra 9223372036854775808 til 9223372036854775807, tar opp 8 byte;
• flytende - flytende kommatall fra -3,4E+38 til 3,4E+38, tar opp 4 byte;
• dobbel — flytende kommatall fra -1,7E+308 til 1,7E+308, tar opp 8 byte;
• char — enkelttegn i UTF-16, tar opp 2 byte;
• boolske sanne/falske verdier, tar opp 1 byte.

Og det er referansedatatyper som peker til objekter på haugen.

3. Hvordan skiller et objekt seg fra primitive datatyper?

Den første forskjellen er mengden minne som er opptatt: primitiver tar opp svært lite fordi de bare inneholder sin egen verdi, men objekter kan inneholde mange forskjellige verdier - både primitiver og referanser til andre objekter. En annen forskjell er dette: Java er et objektorientert språk, så alt i Java fungerer er en interaksjon mellom objekter. Primitiver passer ikke så godt inn her. Faktisk er det derfor Java ikke er et 100% objektorientert språk. Den tredje forskjellen, som følger av den andre, er at fordi Java er fokusert på objektinteraksjoner, er det mange forskjellige mekanismer for å administrere objekter. For eksempel konstruktører, metoder, unntak (som først og fremst fungerer med objekter), osv. Og for å la primitiver på en eller annen måte fungere i dette objektorienterte miljøet, kom Javas skapere opp medomslag for de primitive typene ( heltall , tegn , dobbel , boolsk ...)

4. Hva er forskjellen mellom å sende argumenter ved referanse og etter verdi?

Primitive felt lagrer verdien deres: for eksempel hvis vi setter int i = 9; , så lagrer i- feltet verdien 9. Når vi har en referanse til et objekt, betyr det at vi har et felt med en referanse til objektet. Vi har med andre ord et felt som lagrer adressen til objektet i minnet.

Cat cat = new Cat();

Dette betyr at felt med referanse til et objekt også lagrer verdier . Verdiene deres er minneadresser. Det vil si at cat lagrer minneadressen til det nye Cat() -objektet. Når vi sender et argument til en metode, blir verdien kopiert. Når det gjelder en primitiv, kopieres verdien av primitivet. Følgelig fungerer metoden med kopien. Når kopien endres, påvirkes ikke originalen. Ved en referansetype kopieres verdien til minneadressen. Følgelig vil begge referansevariablene lagre adresser som peker til det samme objektet. Og hvis vi bruker denne nye referansen til å endre objektet, vil vi finne at den også endres for den gamle referansen. Tross alt peker de begge på samme objekt.

5. Hva er JVM, JDK og JRE?

JVM står for Java Virtual Machine , som kjører Java-bytekode forhåndsgenerert av kompilatoren. JRE står for Java Runtime Environment . I utgangspunktet er det et miljø for å kjøre Java-applikasjoner. Den inkluderer JVM, standardbiblioteker og andre komponenter for å kjøre appleter og applikasjoner skrevet i programmeringsspråket Java. Med andre ord er JRE en pakke med alt som trengs for å kjøre et kompilert Java-program, men det inkluderer ikke verktøy og verktøy som kompilatorer eller debuggere for å utvikle applikasjoner. JDK står for Java Development Kit , som er en utvidelse av JRE. Det vil si at det er et miljø ikke bare for å kjøre Java-applikasjoner, men også for å utvikle dem. JDK inneholder alt i JRE, pluss diverse tilleggsverktøy – kompilatorer og feilsøkere – som trengs for å lage Java-applikasjoner (inkluderer Java-dokumenter).

6. Hvorfor bruke JVM?

Som nevnt ovenfor er Java Virtual Machine en virtuell maskin som kjører Java-bytekode som er forhåndsgenerert av kompilatoren. Dette betyr at JVM ikke forstår Java-kildekoden. Så først kompilerer vi .java- filer. De kompilerte filene har .classutvidelse og er nå i form av bytekode, som JVM forstår. JVM er forskjellig for hvert operativsystem. Når JVM kjører bytekodefiler, tilpasser den dem til operativsystemet den kjører på. Faktisk, fordi det er forskjellige JVM-er, er JDK (eller JRE) også forskjellig for forskjellige OS (hver versjon trenger sin egen JVM). La oss huske hvordan utvikling fungerer i andre programmeringsspråk. Du skriver et program, så blir koden kompilert til maskinkode for et spesifikt operativsystem, og så kan du kjøre det. Du må med andre ord skrive forskjellige versjoner av programmet for hver plattform. Men Javas doble prosessering av koden (kompilering av kildekode til bytekode, og deretter prosessering av bytekode av JVM) lar deg nyte fordelene med en tverrplattformløsning. Vi lager koden én gang og kompilerer den til bytekode. Da kan vi ta det til et hvilket som helst operativsystem, og den opprinnelige JVM er i stand til å kjøre den. Og dette er nettopp Javas legendariskeskriv én gang, kjør hvor som helst funksjon.

7. Hva er bytekode?

Som jeg sa ovenfor, konverterer kompilatoren Java-kode til mellombytekode ( vi går fra filer med filtypen .java til filer med filtypen .class). På mange måter ligner bytekode på maskinkode, bortsett fra at instruksjonssettet ikke er for en ekte prosessor, men en virtuell. Når det er sagt, kan det inkludere seksjoner designet for en JIT-kompilator, som optimerer kommandoutførelse for den faktiske prosessoren programmet kjører på. JIT-kompilering, også kalt on-the-fly kompilering, er en teknologi som øker ytelsen til et bytekodeprogram ved å kompilere bytekoden til maskinkode eller et annet format mens programmet kjører. Som du kanskje har gjettet, bruker JVM JIT-kompilatoren når den kjører bytekode. La oss ta en titt på noen eksempelbytekode: Ikke for lesbart, ikke sant? Den gode nyheten er at denne instruksen ikke er ment for oss. Det er for JVM.

8. Hva er funksjonene til en JavaBean?

En JavaBean er en Java-klasse som følger visse regler. Her er noen av reglene for å skrive en JavaBean :

1. Klassen må inneholde en tom (ingen argument) konstruktør med offentlig tilgangsmodifikator. Denne konstruktøren gjør det mulig å lage et objekt av klassen uten unødvendige problemer (slik at det ikke er unødvendig fikling med argumenter).

2. Interne felt er tilgjengelig via get and set instansmetoder, som bør ha standardimplementeringen. For eksempel, hvis vi har et navnefelt , så bør vi ha getName og setName osv. Dette gjør at ulike verktøy (rammeverk) automatisk kan hente og sette innholdet i bønner uten problemer.

3. Klassen må overstyre metodene equals() , hashCode() , og toString() .

4. Klassen må kunne serialiseres. Det vil si at den må ha grensesnittet Serializable markør eller implementere Externalizable -grensesnittet. Dette er slik at bønnens tilstand kan lagres, lagres og gjenopprettes pålitelig.

9. Hva er en OutOfMemoryError?

OutOfMemoryError er en kritisk kjøretidsfeil relatert til Java Virtual Machine (JVM). Denne feilen oppstår når JVM ikke kan tildele et objekt fordi det ikke er nok minne for det, og søppelsamleren ikke kan tildele mer minne. Noen få typer OutOfMemoryError :

• OutOfMemoryError: Java-haugplass — objektet kan ikke tildeles på Java-heapen på grunn av utilstrekkelig minne. Denne feilen kan være forårsaket av en minnelekkasje eller av en standard haugstørrelse som er for liten for gjeldende applikasjon.

• OutOfMemoryError: GC Overhead-grense overskredet — fordi applikasjonens data så vidt får plass i haugen, kjører søppelsamleren hele tiden, noe som får Java-programmet til å kjøre veldig sakte. Som et resultat overskrides grensen for søppeloppsamleren og applikasjonen krasjer med denne feilen.

• OutOfMemoryError: Forespurt matrisestørrelse overskrider VM-grensen – dette indikerer at applikasjonen prøvde å tildele minne for en matrise som overskrider heapstørrelsen. Igjen kan dette bety at utilstrekkelig minne ble tildelt som standard.

• OutOfMemoryError: Metaspace — haugen gikk tom for plass tildelt for metadata (metadata er instruksjoner for klasser og metoder).

• OutOfMemoryError: be om bytestørrelse for grunn. Tom for bytteplass — det oppstod en feil ved forsøk på å tildele minne fra haugen, og som et resultat mangler haugen tilstrekkelig plass.

10. Hva er en stabelsporing? Hvordan får jeg det?

En stabelsporing er en liste over klassene og metodene som har blitt kalt frem til dette punktet i kjøringen av en applikasjon. Du kan få stabelsporingen på et bestemt punkt i applikasjonen ved å gjøre dette:

StackTraceElement[] stackTraceElements =Thread.currentThread().getStackTrace();

Dette gir oss en rekke StackTraceElements arrangert i Last In First Out (LIFO) rekkefølge. I Java, når folk snakker om en stabelsporing, mener de vanligvis en stabelsporing som vises på konsollen når en feil (eller unntak) oppstår. Du kan få stabelsporet fra unntak som dette:

StackTraceElement[] stackTraceElements;
try{
                ...
} catch (Exception e) {
   stackTraceElements = e.getStackTrace();
}

Og hvis vi vil vise et unntaks stabelsporing på konsollen:

try{
                ...
} catch (Exception e) {
  e.printStackTrace();
}

I tillegg, hvis en feil, ukontrollert unntak eller ubehandlet sjekket unntak oppstår, får vi automatisk unntakets stacksporing på konsollen når applikasjonen krasjer. Her er et lite eksempel på en stabelsporing på konsollen: Og på det notatet vil vi avslutte vår diskusjon om dette emnet i dag.