Fix: Det oppstod en feil under initialiseringen av VM, kunne ikke reservere nok plass til objektbunken
Selv om Java-appletter ikke er en populær webteknologi i disse dager, er det utallige grunner til å distribuere en Java-virtuell maskin direkte på en Linux-server. Hvis du prøver å kjøre Linux java-kommandoen direkte på diskret maskinvare eller inne i sin egen VM, kan det hende du får en "feil oppstod under initialisering av VM kunne ikke reservere nok plass til objektbunke" -meldingen.
Dette ser sannsynligvis ganske rart ut fordi du mer enn sannsynlig har nok RAM til å kjøre kommandoen, men det skyldes i stor grad en spesifikk særegenhet som fysiske og virtuelle minnesider blir vant til. Når du spesifiserer noen relativt store størrelser, kan du omgå denne meldingen og kjøre java-kommandoen slik du ville gjort.
Metode 1: Bruke kommandolinjealternativer
Hvis du har prøvd å kjøre java og fått denne meldingen, har du sannsynligvis allerede kjørt gratis kommandoen for å sikre at det er rikelig med minne å kjøre programmet i.
Legg merke til at på testmaskinen vår hadde vi 2,3 GB fysisk RAM og ikke en eneste side virtuelt minne hadde blitt brukt ennå. Hvis du merker at du har en minneknusing, vil du lukke andre ting du kjører før du prøver det igjen. På den annen side kan de som fant ut at de har rikelig med ledig minne, prøve å spesifisere en størrelse direkte.
For eksempel var vi i stand til å kjøre kommandoen som java -Xms256m -Xmx512M, og det fungerte som det ellers ville blitt forventet. Dette begrenser haugstørrelsen som den virtuelle Java-maskinen prøver å reservere ved oppstart. Siden en uhemmet virtuell maskin hypotetisk kunne gjøre uvanlige ting, kan det kaste feilmeldinger på et ellers gratis system. Det kan også være lurt å leke med de to verdiene før du finner den rette kombinasjonen.
Dette kan være et problem uansett hva du kjører det på, siden JVM ikke har noe å gjøre med typen VM du kan bruke til å kjøre GNU / Linux.
Metode 2: Eksportere variablene for å gjøre endringen permanent
Når du finner en verdi som fungerer, kan du eksportere den for å gjøre den permanent for den økten. For eksempel brukte vi eksport _JAVA_OPTIONS = '- Xms256M -Xmx512M' fra bash-ledeteksten, og det tillot oss å kjøre java-kommandoen av seg selv uten andre alternativer før vi logget av serveren vår.
Det måtte kjøres igjen når vi logget på en annen økt, så du vil kanskje legge den til i relevante oppstartsskript hvis du planlegger å bruke java-kommandoen ganske ofte. Vi la til linjen i .bash_login-filen, og det så ut til å fungere hver gang vi brukte en påloggingsprompt uten å måtte kjøre den igjen, selv om du kanskje må finne et annet sted for det hvis du jobber med et annet skall.
Du har kanskje lagt merke til at bare visse maskinvarekonfigurasjoner utløser denne feilmeldingen. Det er fordi det vanligvis skjer på maskiner med mye fysisk RAM, men lavere ulimiter for hvordan du bruker det. Java vil prøve å tildele en enorm blokk bare for å få beskjed om at den ikke kan, som den tolker som tom for minne.
Metode 3: Skrive ut gjeldende Java-alternativer
Hvis du har jobbet på kommandolinjen og vil ha en rask referanse til hva du for øyeblikket har satt _JAVA_OPTIONS-verdien til, så kjører du bare ekko $ _JAVA_OPTIONS, og den vil umiddelbart skrive ut de nåværende verdiene. Dette er nyttig for feilsøking når du prøver å finne ut de riktige tallene du kan prøve.
Husk at selv om denne løsningen ikke krever noe annet å spille rundt, vil Java kaste ut "kunne ikke reservere nok plass til objektbunke" -meldingen hvis du noen gang befinner deg virkelig i den korte enden av virtuelt minne. Hvis dette er tilfelle, vil du dobbeltsjekke hvilke prosesser som kjører for øyeblikket, og muligens starte serveren på nytt hvis det er et alternativ. Du kan også skape mer bytteplass, men hvis dette er et problem, er det generelt bedre å prøve å rette det på en annen måte.
I sjeldne tilfeller at innstillingene dine ser ut til å være riktige, men det fortsatt ikke fungerer, må du sørge for at du har installert 64-biters Java-pakken, siden den burde være immun mot dette problemet. Sammenhengende minnekrav gjelder bare for 32-biters versjon av Java. Vi fant i en håndfull tilfeller at 64-biters versjonen prøvde å lage en 32-biters virtuell maskin, så å spesifisere alternativet -d64 på kommandolinjen fikset det for oss.
