Jeg arbejder for nylig på et program til Java. Oprindeligt har jeg altid kunnet lide Javas hukommelsesstyring, der er ingen grund til at bekymre sig om at allokere hukommelse, bare alloker, garbage collector vil genvinde hukommelsen for dig. Nu er programmet udviklet med en stor mængde data, og for hastighedens skyld vil jeg indlæse al informationen i hukommelsen, hvilket sikrer et hurtigt svar. Jeg tæller stadig hukommelsen gentagne gange og tænker på min egen datamængde, hvilket burde være nok i starten (min maskine har 4G-hukommelse, selvom Windows genkender 3,5G, men det burde være fint sammenlignet med mit nuværende datavolumen).
Uventet kørte programmet for det første eksperiment i et par timer og stødte på en Out of Memory-undtagelse. Når jeg kigger på mine egne VM-indstillinger, sætter jeg -Xms512M -Xmx1024M. Uden at tænke over det ændrede jeg det direkte til -Xms512M -Xmx2048M, og resultatet var, at jeg ikke kunne reservere nok plads til objektheap. Programmet kan ikke rejse sig. Først da indså jeg, at der stadig var en grænse for den oprindelige maksimale hukommelse. Jeg søgte på internettet og fandt mange artikler, der diskuterede dette emne. Endelig fandt jeg den mest nyttige artikel på BEAs DEV2DEV-forum
Her lavede moderator YuLimin testen og nåede frem til konklusionen:
Firmaets JVM-version Maksimal hukommelse (mega) klient Maksimal hukommelse (mega) server
SØN 1.5.x 1492 1520
SUN 1.5.5(Linux) 2634 2660
SØN 1.4.2 1564 1564
SUN 1.4.2(Linux) 1900 1260
IBM 1.4.2(Linux) 2047 N/A
BEA JRockit 1.5 (U3) 1909 1902
Jeg bruger JDK1.6.0_05 nu, har testet det. Det største problem i klienttilstanden er, at min JDK ikke genkender -Server-parameteren og ikke kan teste serverens tilstand. Estimaterne er omtrent de samme.
SØN 1.6.0 1442 N/a
Det virker som om, det er umuligt at bruge stor hukommelse i Java. Og det generelle ordsprog er, at hvis hukommelsen er for stor, vil affaldsindsamlingstiden være lang. Dette er også forståeligt, generelt indsamlet, når hukommelsen ikke er nok, scanning af 2G-hukommelse er selvfølgelig meget langsommere end 1G, og der er flere hukommelsesobjekter, den estimerede relation vokser eksponentielt.
Vedhæftet nedenfor er YuLimins testmetoder og testoptegnelser.
Testmetode: Brug kommandoen java -XmxXXXXM -version til at teste på kommandolinjen, og øg derefter gradvist værdien af XXXX; hvis det kører normalt, betyder det, at den angivne hukommelsesstørrelse er tilgængelig, ellers vil der blive udskrevet en fejlmeddelelse. |
Opslået på 24/07/2017 10.43.36
|
|
|
|
Udlejer