Onlangs werk ik aan een programma voor Java. Oorspronkelijk vond ik Java's geheugenbeheer altijd prettig, je hoeft je geen zorgen te maken over het toewijzen van geheugen, gewoon toewijzen, de garbage collector zal het geheugen voor je terugwinnen. Nu is het programma ontwikkeld met een grote hoeveelheid data, en voor het tempo ga ik alle informatie in het geheugen laden, wat zorgt voor een snelle reactie. Ik tel nog steeds herhaaldelijk het geheugen, denk aan mijn eigen datavolume, wat in het begin voldoende zou moeten zijn (mijn machine heeft 4G-geheugen, hoewel Windows 3,5G herkent, maar dat zou prima moeten zijn vergeleken met mijn huidige datavolume).
Onverwacht liep het programma van het eerste experiment enkele uren en kwam een Out of Memory Exception tegen. Als ik naar mijn eigen VM-instellingen kijk, stel ik -Xms512M -Xmx1024M in. Zonder erover na te denken heb ik het direct veranderd naar -Xms512M -Xmx2048M, en het resultaat was dat ik niet genoeg ruimte kon reserveren voor object heap. Het programma kan niet opstaan. Pas toen realiseerde ik me dat er nog steeds een limiet was aan het oorspronkelijke maximale geheugen. Ik heb op internet gezocht en veel artikelen gevonden die dit onderwerp bespreken. Uiteindelijk vond ik het meest nuttige artikel op het DEV2DEV forum van BEA
Hier deed moderator YuLimin de test en kwam tot de conclusie:
Bedrijf JVM-versie Maximale geheugen (mega) client Maximale geheugen (mega) server
ZO 1.5.x 1492 1520
SUN 1.5.5(Linux) 2634 2660
ZO 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
Ik gebruik JDK1.6.0_05 nu, heb het getest. Het grootste probleem in de clientstatus is dat mijn JDK de -Serverparameter niet herkent en de serverstatus niet kan testen. De schattingen zijn ongeveer hetzelfde.
ZON 1.6.0 1442 N/a
Het lijkt onmogelijk om groot geheugen in Java te gebruiken. En het algemene gezegde is dat als het geheugen te groot is, de tijd voor het opruimen van het afval lang zal zijn. Dit is ook begrijpelijk, meestal verzameld wanneer het geheugen niet genoeg is, het scannen van 2G-geheugen is natuurlijk veel langzamer dan 1G, en er zijn meer geheugenobjecten, de geschatte relatie neemt exponentieel toe.
Hieronder staan de testmethoden en testgegevens van YuLimin bijgevoegd.
Testmethode: Gebruik het java -XmxXXXXM -version commando om op de commandoregel te testen en verhoog vervolgens geleidelijk de waarde van XXXX; als het normaal draait, betekent dit dat de gespecificeerde geheugengrootte beschikbaar is, anders wordt er een foutmelding afgedrukt. |
Geplaatst op 24-07-2017 10:43:36
|
|
|
|
Huisbaas