Constructor Return Type i Java

1. Oversikt

I denne raske opplæringen skal vi fokusere på returtypen for en konstruktør i Java.

Først blir vi kjent med hvordan objektinitialisering fungerer i Java og JVM. Deretter graver vi dypere for å se hvordan objektinitialisering og oppgave fungerer under panseret.

2. Instans initialisering

La oss starte med en tom klasse:

offentlig klasse Farge {}

Her skal vi lage en forekomst fra denne klassen og tildele den til en eller annen variabel:

Farge farge = ny Farge ();

Etter å ha samlet denne enkle Java-kodebiten, la oss ta en titt på bytekoden via javap -c kommando:

0: ny # 7 // klasse Farge 3: dup 4: invokespesial # 9 // Metodefarge. "" :() V 7: astore_1

Når vi instantierer et objekt i Java, utfører JVM følgende operasjoner:

  1. Først finner den et sted i prosessområdet for det nye objektet.
  2. Deretter utfører JVM systeminitialiseringsprosessen. I dette trinnet oppretter det objektet i standardtilstand. De ny opcode i bytecode er faktisk ansvarlig for dette trinnet.
  3. Til slutt initialiserer den objektet med konstruktøren og andre initialiseringsblokker. I dette tilfellet invokespesial opcode kaller konstruktøren.

Som vist ovenfor er metodesignaturen for standardkonstruktøren:

Metodefarge. "" :() V

De er navnet på forekomst initialiseringsmetoder i JVM. I dette tilfellet er en funksjon som:

  • tar ingenting som inngang (tomme parenteser etter metodens navn)
  • returnerer ingenting (V står for tomrom)

Derfor er returtypen til en konstruktør i Java og JVM tomrom.

Ta en ny titt på vår enkle oppgave:

Farge farge = ny Farge ();

Nå som vi vet at konstruktøren kommer tilbake tomrom, la oss se hvordan oppgaven fungerer.

3. Hvordan oppdrag fungerer

JVM er en stabelbasert virtuell maskin. Hver bunke består av stabelrammer. Enkelt sagt tilsvarer hver stabelramme en metodeanrop. Faktisk lager JVM rammer med en ny metodeanrop og ødelegger dem når de fullfører jobben:

Hver stabelramme bruker en matrise for å lagre lokale variabler og en operandstabel for å lagre delvise resultater. Gitt det, la oss ta en ny titt på bytekoden:

0: ny # 7 // klasse Farge 3: dup 4: invokespesial # 9 // Metodefarge. "" :() V 7: astore_1

Slik fungerer oppgaven:

  • De ny instruksjon skaper en forekomst av Farge og skyver referansen på operandstakken
  • De dup opcode dupliserer det siste elementet i operandstakken
  • De invokespesial tar den dupliserte referansen og bruker den til initialisering. Etter dette gjenstår bare den originale referansen på operandstakken
  • De astore_1 lagrer den opprinnelige referansen til indeks 1 i matrisen for lokale variabler. Prefikset “a” betyr at elementet som skal lagres er en objektreferanse, og “1” er matriseindeksen

Fra nå av, det andre elementet (indeks 1) i matrisen for lokale variabler er en referanse til det nylig opprettede objektet. Derfor mister vi ikke referansen, og oppgaven fungerer faktisk - selv når konstruktøren ikke gir noe tilbake!

4. Konklusjon

I denne raske opplæringen lærte vi hvordan JVM oppretter og initialiserer klasseinstanser. Videre så vi hvordan initialiseringen av forekomsten fungerer under panseret.

For en enda mer detaljert forståelse av JVM, er det alltid lurt å sjekke spesifikasjonen.


$config[zx-auto] not found$config[zx-overlay] not found