Udforske spørgsmål og svar fra en jobsamtale til en Java-udviklerstilling. Del 1

Hej! CodeGym har samlet en mangfoldig gruppe mennesker. Nogle af os ønsker intet mere end at blive Java-udviklere, og vi investerer meget tid og kræfter i udvikling. Andre er allerede Java-udviklere. I begge tilfælde skal du være klar til at blive testet i tekniske interviews. Disse er ikke nemme. De kræver både følelsesmæssig og teknisk forberedelse. Jeg stødte for nylig på et par store lister med interviewspørgsmål til Java-udviklerstillinger. Spørgsmålene er opdelt i forskellige niveauer: junior, mid-level og senior. Bliv ikke foruroliget: Ikke alle spørgsmål er nemme, men dem med en stjerne bliver sjældent stillet. Spørgsmålene er gode, og jeg vil gerne forsøge at besvare de fleste af dem. Det er klart, at det hele ikke passer i en enkelt artikel. Der er jo mange spørgsmål der. Det betyder, at der vil være en hel række artikler med svar på disse interviewspørgsmål. Lad mig understrege et par punkter med det samme: svarene bliver korte, fordi svar, der er skrevet meget detaljeret, kan trækkes ud i en separat artikel. Ved interviews ønskes der heller ikke super detaljerede og omfangsrige svar, fordi din interviewer kun har en time til at interviewe dig om væsentlige emner (og,

Q&A til en junior udviklerstilling

Generelle spørgsmål

1. Hvilke designmønstre kender du? Fortæl os om to designmønstre, som du har brugt i dit arbejde.

Der er et stort udvalg af mønstre. Til jer, der gerne vil sætte jer grundigt ind i designmønstre, anbefaler jeg at læse bogen "Hoved først. Designmønstre". Det vil hjælpe dig med nemt at lære detaljerne i de mest grundlæggende designmønstre. Med hensyn til designmønstre, som du kunne nævne i en jobsamtale, kommer følgende til at tænke på:

• Builder — en ofte brugt skabelon, et alternativ til den klassiske tilgang til objektskabelse;
• Strategi - et mønster, der i det væsentlige repræsenterer polymorfi. Det vil sige, at vi har én grænseflade, men programmets adfærd ændrer sig afhængigt af den specifikke grænsefladeimplementering, der overføres til funktionen (strategimønsteret bruges nu stort set overalt i Java-applikationer).

Hvis det ikke er nok for dig, så vær opmærksom på Spring (hvis du allerede kender det), for det er en hel platform af rammer, som igen er gennemsyret af mønstre fra start til slut. Her er et par eksempler på, hvad jeg taler om:

• Factory — dette mønster kan findes i ApplicationContext (eller i BeanFactory);
• Singleton — alle bønner er singletons som standard;
• Proxy — grundlæggende bruger alt i foråret dette mønster på en eller anden måde, for eksempel AOP;
• Ansvarskæde — et mønster, der understøtter Spring Security;
• Skabelon — brugt i Spring JDBC.

Java Core

2. Hvilke datatyper findes der i Java?

Java har følgende primitive datatyper:

• byte — heltal fra -128 til 127, fylder 1 byte;
• kort — heltal fra -32768 til 32767, fylder 2 bytes;
• int — heltal fra -2147483648 til 2147483647, fylder 4 bytes;
• lang — heltal fra 9223372036854775808 til 9223372036854775807, fylder 8 bytes;
• flydende — flydende kommatal fra -3,4E+38 til 3,4E+38, fylder 4 bytes;
• dobbelt — flydende kommatal fra -1,7E+308 til 1,7E+308, fylder 8 bytes;
• char — enkelte tegn i UTF-16, fylder 2 bytes;
• booleske sande/falske værdier, fylder 1 byte.

Og der er referencedatatyper, der peger på objekter på heapen.

3. Hvordan adskiller et objekt sig fra primitive datatyper?

Den første forskel er mængden af ​​optaget hukommelse: primitiver fylder meget lidt, fordi de kun indeholder deres egen værdi, men objekter kan indeholde mange forskellige værdier - både primitiver og referencer til andre objekter. En anden forskel er denne: Java er et objektorienteret sprog, så alt i Java fungerer er en interaktion mellem objekter. Primitiver passer ikke særlig godt ind her. Faktisk er det derfor, Java ikke er et 100% objektorienteret sprog. Den tredje forskel, som følger af den anden, er, at fordi Java er fokuseret på objektinteraktioner, er der mange forskellige mekanismer til at styre objekter. For eksempel konstruktører, metoder, undtagelser (som primært arbejder med objekter) osv. Og for at tillade primitiver på en eller anden måde at fungere i dette objektorienterede miljø, fandt Javas skabere op medomslag til de primitive typer ( heltal , tegn , dobbelt , boolesk ...)

4. Hvad er forskellen mellem at videregive argumenter ved reference og efter værdi?

Primitive felter gemmer deres værdi: for eksempel, hvis vi sætter int i = 9; , så gemmer i- feltet værdien 9. Når vi har en reference til et objekt, betyder det, at vi har et felt med en reference til objektet. Med andre ord har vi et felt, der gemmer adressen på objektet i hukommelsen.

Cat cat = new Cat();

Det betyder, at felter med en reference til et objekt også gemmer værdier . Deres værdier er hukommelsesadresser. Det vil sige, at cat gemmer hukommelsesadressen på det nye Cat() objekt. Når vi sender et argument til en metode, kopieres dets værdi. I tilfælde af en primitiv kopieres værdien af ​​primitivet. Følgelig fungerer metoden med kopien. Når kopien ændres, påvirkes originalen ikke. I tilfælde af en referencetype kopieres værdien af ​​hukommelsesadressen. Følgelig vil begge referencevariabler gemme adresser, der peger på det samme objekt. Og hvis vi bruger denne nye reference til at ændre objektet, så vil vi opdage, at det også er ændret for den gamle reference. De peger jo begge på det samme objekt.

5. Hvad er JVM, JDK og JRE?

JVM står for Java Virtual Machine , som kører Java-bytekode, der er prægenereret af compileren. JRE står for Java Runtime Environment . Grundlæggende er det et miljø til at køre Java-applikationer. Det inkluderer JVM, standardbiblioteker og andre komponenter til at køre applets og applikationer skrevet i Java-programmeringssproget. Med andre ord er JRE en pakke med alt det nødvendige for at køre et kompileret Java-program, men det inkluderer ikke værktøjer og hjælpeprogrammer såsom kompilatorer eller debuggere til udvikling af applikationer. JDK står for Java Development Kit , som er en udvidelse af JRE. Det vil sige, at det ikke kun er et miljø til at køre Java-applikationer, men også til at udvikle dem. JDK'et indeholder alt i JRE, plus forskellige yderligere værktøjer - compilere og debuggere - der er nødvendige for at skabe Java-applikationer (inklusive Java-dokumenter).

6. Hvorfor bruge JVM?

Som nævnt ovenfor er Java Virtual Machine en virtuel maskine, der kører Java-bytekode, der er prægenereret af compileren. Dette betyder, at JVM ikke forstår Java-kildekoden. Så først kompilerer vi .java- filer. De kompilerede filer har .classudvidelse og er nu i form af bytekode, som JVM forstår. JVM er forskellig for hvert OS. Når JVM'en kører bytecode-filer, tilpasser den dem til det operativsystem, den kører på. Faktisk, fordi der er forskellige JVM'er, er JDK (eller JRE) også forskellig for forskellige OS (hver version har brug for sin egen JVM). Lad os huske, hvordan udvikling fungerer i andre programmeringssprog. Du skriver et program, så kompileres dets kode til maskinkode til et bestemt OS, og så kan du køre det. Du skal med andre ord skrive forskellige versioner af programmet til hver platform. Men Javas dobbelte behandling af koden (kompilering af kildekode til bytekode og derefter behandling af bytekode af JVM) giver dig mulighed for at nyde fordelene ved en cross-platform løsning. Vi opretter koden én gang og kompilerer den til bytekode. Så kan vi tage det til et hvilket som helst OS, og det oprindelige JVM er i stand til at køre det. Og dette er netop Javas legendariskeskriv én gang, kør hvor som helst funktion.

7. Hvad er bytekode?

Som jeg sagde ovenfor, konverterer compileren Java-kode til mellembytekode ( vi går fra filer med filtypenavnet .java til filer med filtypenavnet .class). På mange måder ligner bytekode maskinkode, bortset fra at dets instruktionssæt ikke er til en rigtig processor, men en virtuel. Når det er sagt, kan det inkludere sektioner designet til en JIT-compiler, som optimerer kommandoudførelsen for den faktiske processor, programmet kører på. JIT-kompilering, også kaldet on-the-fly kompilering, er en teknologi, der øger et bytekodeprograms ydeevne ved at kompilere bytekoden til maskinkode eller et andet format, mens programmet kører. Som du måske har gættet, bruger JVM JIT-kompileren, når den kører bytekode. Lad os tage et kig på nogle eksempler på bytekode: Ikke for læseligt, vel? Den gode nyhed er, at denne instruktion ikke er beregnet til os. Det er til JVM.

8. Hvad er funktionerne ved en JavaBean?

En JavaBean er en Java-klasse, der følger visse regler. Her er nogle af reglerne for at skrive en JavaBean :

1. Klassen skal indeholde en tom (ingen argument) konstruktør med offentlig adgangsmodifikator. Denne konstruktør gør det muligt at skabe et objekt af klassen uden unødvendige problemer (så der ikke er unødvendigt fiflen med argumenter).

2. Der tilgås interne felter via get and set instansmetoder, som bør have standardimplementeringen. For eksempel, hvis vi har et navnefelt , så skal vi have getName og setName osv. Dette gør det muligt for forskellige værktøjer (frameworks) automatisk at hente og indstille indholdet af bønner uden problemer.

3. Klassen skal tilsidesætte equals() , hashCode() og toString() metoderne.

4. Klassen skal kunne serialiseres. Det vil sige, at den skal have Serializable markør-grænsefladen eller implementere Externalizable- grænsefladen. Dette er for at bønnens tilstand pålideligt kan gemmes, lagres og gendannes.

9. Hvad er en OutOfMemoryError?

OutOfMemoryError er en kritisk runtime-fejl relateret til Java Virtual Machine (JVM). Denne fejl opstår, når JVM'en ikke kan allokere et objekt, fordi der ikke er nok hukommelse til det, og garbage collectoren ikke kan allokere mere hukommelse. Et par typer OutOfMemoryError :

• OutOfMemoryError: Java-heap-plads — objektet kan ikke allokeres på Java-heapen på grund af utilstrækkelig hukommelse. Denne fejl kan være forårsaget af en hukommelseslækage eller af en standard heapstørrelse, der er for lille til den aktuelle applikation.

• OutOfMemoryError: GC Overhead-grænsen er overskredet — fordi applikationens data næsten ikke passer i dyngen, kører garbage collector hele tiden, hvilket får Java-programmet til at køre meget langsomt. Som et resultat overskrides grænsen for skraldeopsamlerens overhead, og applikationen går ned med denne fejl.

• OutOfMemoryError: Den anmodede matrixstørrelse overstiger VM-grænsen — dette indikerer, at applikationen forsøgte at allokere hukommelse til et array, der overstiger heapstørrelsen. Igen kan dette betyde, at der som standard blev tildelt utilstrækkelig hukommelse.

• OutOfMemoryError: Metaspace — heapen løb tør for plads allokeret til metadata (metadata er instruktioner til klasser og metoder).

• OutOfMemoryError: anmod om bytesstørrelse af årsag. Ud af swap-plads — der opstod en fejl under forsøg på at allokere hukommelse fra heapen, og som følge heraf mangler heapen tilstrækkelig plads.

10. Hvad er et stakspor? Hvordan får jeg det?

En staksporing er en liste over de klasser og metoder, der er blevet kaldt frem til dette tidspunkt i udførelsen af ​​en applikation. Du kan få staksporet på et bestemt punkt i applikationen ved at gøre dette:

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

Dette giver os en række StackTraceElements arrangeret i Last In First Out (LIFO) rækkefølge. I Java, når folk taler om en stak-sporing, mener de normalt en stak-sporing, der vises på konsollen, når der opstår en fejl (eller undtagelse). Du kan få staksporet fra undtagelser som dette:

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

Og hvis vi vil vise en undtagelses staksporing på konsollen:

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

Derudover, hvis der opstår en fejl, umarkeret undtagelse eller uhåndteret markeret undtagelse, får vi automatisk undtagelsens staksporing på konsollen, når applikationen går ned. Her er et lille eksempel på et stakspor på konsollen: Og på den note afslutter vi vores diskussion af dette emne i dag.