streamalism.org

1. Oversikt

I denne opplæringen lærer vi årsaken til “Kunne ikke reservere nok plass til objektbunke” feil, mens du går gjennom noen mulige scenarier.

2. Symptomer

"Kunne ikke reservere nok plass til objektbunke" er en spesifikk JVM-feil som heves når Java-prosessen kan ikke opprettevirtuell maskin på grunn av minnebegrensninger som oppstår på det kjørende systemet:

java -Xms4G -Xmx4G -jar HelloWorld.jar Feil oppstod under initialisering av VM Kunne ikke reservere nok plass til objektbunke Feil: Kunne ikke opprette Java Virtual Machine. Feil: Det har skjedd et dødelig unntak. Programmet vil avslutte.

Generelt er det to mulige scenarier når vi støter på feilen.

For det første når vi spiser lunsj på en Java-prosess med maksimumsgrense parameter for haug-Xmx) og verdien ermer enn hva prosessen kan ha på operativsystemet.

Grensen for haugstørrelse varierer basert på flere begrensninger:

• maskinvarearkitektur (32/64 bit)
• JVM bitversjon (32/64 bit)
• operativsystemet vi bruker

For det andre, når Java-prosessen klarer ikke å reservere den angitte mengden minne på grunn av andre applikasjoner som kjører på samme system og bruker minne.

3. Haugestørrelse

Java haugplass er minnetildelingsbassenget for runtime Java-programmet, administrert av JVM selv. Som standard, tildelingsbassenget er begrenset til den innledende og maksimale størrelsen. For å lære mer om Heap Space i Java, ta en titt på denne artikkelen her.

La oss se hva den maksimale haugestørrelsen er i forskjellige miljøer og hvordan vi kan sette grensene.

3.1. Maks haugstørrelse

Den maksimale teoretiske heapgrensen for 32-biters og 64-biters JVM er enkel å bestemme ved å se på ledig minne, 2 ^ 32 (4 GB) for 32-biters JVM og 2 ^ 64 (16 Exabyte) for 64- litt JVM.

I praksis, på grunn av ulike begrensninger, kan grensen være mye lavere og varierer gitt operativsystemet. For eksempel, På 32-biters Windows-systemer er det maksimale rekkevidden for bunke mellom 1,4 GB og 1,6 GB. I motsetning til dette, på 32-biters Linux-systemer, kan den maksimale dyngstørrelsen strekke seg opptil 3 GB.

Av denne grunn, Hvis applikasjonen krever en stor haug, bør vi bruke 64-biters JVM. Imidlertid, med en stor haug, vil søppeloppsamleren ha mer arbeid å gjøre, så det er viktig å finne en god balanse mellom haugstørrelse og ytelse.

3.2. Hvordan kontrollere høydestørrelsesgrenser?

Vi har to alternativer for å kontrollere haugstørrelsesgrensene til en JVM.

Først ved å bruke Java kommandolinjeparametere ved hver JVM-initialisering:

-Xms Angir innledende Java-heap-størrelse. Denne verdien må være et multiplum på 1024 og større enn 1 MB. -Xmx Angir maksimal Java-dyngestørrelse. Denne verdien må være et multiplum på 1024 og større enn 2 MB. -Xmn Angir start- og maksimumsstørrelsen (i byte) på dyngen for den unge generasjonen.

For størrelsesverdien kan vi legge til brev k eller K, m eller M og g eller G for å indikere henholdsvis kilobyte, megabyte og gigabyte. Hvis ingen bokstaver er spesifisert, brukes standardenheten (byte).

-Xmn2g -Xmn2048m -Xmn2097152k -Xmn2147483648

For det andre ved å bruke miljøvariabel JAVA_OPTS for å konfigurere over Java-kommandolinjeparametere globalt. På grunn av dette vil hver JVM-initialisering på systemet automatisk bruke konfigurasjonene som er angitt i miljøvariabelen.

JAVA_OPTS = "- Xms256m -Xmx512m"

For mer informasjon, sjekk ut vår omfattende JVM Parameter guide.

4. Konklusjon

I denne opplæringen diskuterte vi to mulige scenarier når JVM ikke er i stand til det reserver nok plass til gjenstandsbunke. Vi lærte også hvordan du kan kontrollere begrensningene for haugstørrelse for å redusere denne feilen.

Deretter lærer du mer om potensielle minneproblemer ved kjøretid og hvordan du identifiserer dem.