Java Heap Space Memory med Runtime API

1. Oversikt

I denne artikkelen vil vi diskutere APIene som tilbys av Java, som kan hjelpe oss med å forstå de mange aspektene relatert til Java-heap space.

Dette kan være nyttig for å forstå gjeldende minnestatus for JVM og outsource den til overvåkingstjenester som StatsD og Datadog, som deretter kan konfigureres til å ta forebyggende tiltak og unngå applikasjonsfeil.

2. Få tilgang til minneparametere

Hver Java-applikasjon har en enkelt forekomst av java.lang.Runtime som kan hjelpe oss å forstå gjeldende minnestatus for applikasjonen. De Runtime # getRuntime statisk metode kan kalles for å få singleton Kjøretid forekomst.

2.1. Totalt minne

De Runtime # getTotalMemory metoden returnerer den totale hopeplassen som for øyeblikket er reservert av JVM i byte. Den inkluderer minnet som er reservert for nåværende og fremtidige objekter. Derfor er det ikke garantert å være konstant under programutførelsen, siden Java-dyngeplassen kan utvides eller reduseres etter hvert som flere objekter blir tildelt.

Også, denne verdien er ikke nødvendigvis det som er i bruk eller maksimalt tilgjengelig minne.

2.2. Gratis minne

De Runtime # freeMemory metoden returnerer ledig dyngplass tilgjengelig for nye objektallokeringer i byte. Det kan øke som et resultat av en søppeloppsamling der mer ledig minne er tilgjengelig etter.

2.3. Maksimalt minne

De Runtime # maxMemory metoden returnerer maksimalt minne som JVM vil prøve å bruke. Når JVM-minnebruk når denne verdien, vil den ikke tildele mer minne og i stedet, og det vil søppeloppsamling oftere.

Hvis JVM-objektene fortsatt trenger mer minne, selv etter at søppeloppsamleren er kjørt, kan JVM kaste et java.lang.OutOfMemoryError kjøretid unntak.

3. Eksempel

I eksemplet nedenfor initialiserer vi en ArrayList og legg til elementer i den mens du holder rede på JVM-heap-plassen ved å bruke de tre metodene ovenfor:

ArrayList arrayList = ny ArrayList (); System.out.println ("i \ t ledig minne \ t totalt minne \ t maksimalt minne"); for (int i = 0; i <1000000; i ++) {arrayList.add (i); System.out.println (i + "\ t" + Runtime.getRuntime (). FreeMemory () + "\ t \ t" + Runtime.getRuntime (). TotalMemory () + "\ t \ t" + Runtime.getRuntime () .maxMemory ()); } // ...
Output: i Free Memory Totalt minne Max Memory 0 254741016 257425408 3817865216 1 254741016 257425408 3817865216 ... 1498 254741016 257425408 3817865216 1499 253398840 257425408 3817865216 1500 253398840 257425408 3817865216 ... 900079 179608120 260046848 3817865216 900 080 302 140 152 324 534 272 3817865216 900 081 302 140 152 324 534 272 3817865216 ...
  • Rad 1498: The Runtime # freeMemory verdien reduseres når nok objekter tildeles plass i Java-bunken.
  • Rad 900080: På dette tidspunktet har JVM mer plass tilgjengelig ettersom GC har kjørt, derav verdiene til Runtime # freeMemory og Runtime # totalMemory øke.

Verdiene vist ovenfor forventes å være forskjellige på hver kjøring av et Java-program.

4. Tilpasse minneparametere

Vi kan overstyre standardverdiene for JVM-minneparameterne ved å sette tilpassede verdier til visse flagg når vi kjører Java-programmet vårt for å oppnå ønsket minneytelse:

  • -Xms: Verdien tildelt -Xms flagg angir start- og minimumsverdien til Java-bunken. Den kan brukes i tilfeller der applikasjonen vår krever mer minne enn standard minimum når du starter JVM
  • -Xmx: På samme måte kan vi sette maksimumsverdien for dyngerommet ved å tilordne den til -Xmx flagg. Den kan brukes når vi vil begrense mengden minne som applikasjonen vår bruker, med vilje.

Vær også oppmerksom på at -Xms verdien må være lik eller mindre enn -Xmx verdi.

4.1. Bruk

java -Xms32M -Xmx64M Hovedfri minne: 31792664 byte Totalt minne: 32505856 byte Maks minne: 59768832 byte java -Xms64M -Xmx64M Hovedfrie minne: 63480640 byte Totalt minne: 64487424 byte Maks minne: 64487424 byte java -Xms64M -Xmx32 under initialisering av VM Innledende dyngestørrelse satt til en større verdi enn den maksimale haugstørrelsen

5. Konklusjon

I denne artikkelen har vi sett hvordan du kan hente JVM-minneverdier via Kjøretid klasse. Disse metodene kan være nyttige når du undersøker JVM-minnelekkasjer og andre ytelsesrelaterte problemer med JVM-minne.

Vi har også vist hvordan du tilordner egendefinerte verdier for visse flagg som fører til forskjellig JVM-minneadferd for forskjellige scenarier.


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