Pagpili ng isang kolektor ng basura sa Java

7.1* Paano pumili ng tamang tagakolekta ng basura

Kung ang iyong application ay walang mahigpit na mga kinakailangan sa latency, dapat mo lang patakbuhin ang application at hayaan ang JVM mismo na pumili ng tamang kolektor.

Sa karamihan ng mga kaso, gumagana nang maayos ang mga default na setting. Kung kinakailangan, maaari mong ayusin ang laki ng heap upang mapabuti ang pagganap. Kung ang pagganap ay hindi pa rin tulad ng inaasahan, subukang baguhin ang kolektor upang umangkop sa mga kinakailangan ng iyong aplikasyon.

• Sequential . Kung ang application ay may maliit na set ng data (hanggang sa humigit-kumulang 100 MB) at/o ito ay tatakbo sa isang processor nang walang anumang mga kinakailangan sa latency.
• Parallel . Kung ang priyoridad ay ang pinakamataas na pagganap ng aplikasyon at walang mga kinakailangan sa latency (o ang mga pag-pause ng isang segundo o higit pa ay katanggap-tanggap).
• CMS/G1 . Kung ang oras ng pagtugon ay mas mahalaga kaysa sa pangkalahatang throughput, at ang mga paghinto ng pagkolekta ng basura ay dapat na mas maikli sa isang segundo.
• ZGC . Kung ang oras ng pagtugon ay mataas ang priyoridad at/o isang napakalaking heap ang kasangkot.

7.2* Mga rekomendasyon para sa pagkolekta ng basura

Iwasan ang mga manual trigger

Bilang karagdagan sa mga pangunahing mekanismo ng pangongolekta ng basura, ang isa sa pinakamahalagang punto tungkol sa prosesong ito sa Java ay hindi ito deterministiko. Ibig sabihin, imposibleng mahulaan kung kailan ito eksaktong magaganap sa oras ng pagtakbo.

Gamit ang System.gc() o Runtime.gc() na mga pamamaraan, maaari kang magsama ng pahiwatig sa iyong code para simulan ang garbage collector, ngunit hindi nito ginagarantiyahan na ito ay talagang tatakbo.

Gumamit ng mga tool sa pagsusuri

Kung wala kang sapat na memorya upang patakbuhin ang iyong application, makakaranas ka ng mga pagbagal, mahabang oras ng pagkolekta ng basura, mga kaganapang "world stop", at kalaunan ay mga error na wala sa memorya. Ito ay maaaring magpahiwatig na ang heap ay masyadong maliit, ngunit maaari rin itong magpahiwatig na ang application ay may memory leak.

Maaari kang gumamit ng tool sa pagsubaybay tulad ng jstat o Java Flight Recorder upang makita kung ang paggamit ng heap ay lumalaki nang walang katapusan, na maaaring magpahiwatig ng isang bug sa code.

Mas gusto ang mga default na setting

Kung mayroon kang maliit, standalone na Java application, malamang na hindi mo na kailangang mag-set up ng koleksyon ng basura. Ang mga default na setting ay magsisilbi sa iyo nang maayos.

Gumamit ng mga flag ng JVM para i-customize

Ang pinakamahusay na diskarte sa pag-set up ng koleksyon ng basura sa Java ay ang magtakda ng mga flag ng JVM. Maaaring gamitin ang mga flag para itakda ang kolektor ng basura (halimbawa, Serial, G1, at iba pa), ang inisyal at maximum na laki ng heap, ang laki ng mga partition ng heap (halimbawa, Young generation, Old generation), at marami pang iba. higit pa.

Piliin ang tamang gripo

Ang isang magandang alituntunin sa mga tuntunin ng mga paunang setting ay ang likas na katangian ng custom na application. Halimbawa, ang kasabay na tagakolekta ng basura ay mahusay, ngunit madalas na nagtataas ng mga kaganapang "paghinto sa mundo", na ginagawang mas angkop para sa panloob na pagproseso kung saan ang mga mahabang paghinto ay katanggap-tanggap.

Kasabay nito, ang CMS garbage collector ay idinisenyo upang mabawasan ang latency, na ginagawang perpekto para sa mga web application kung saan mahalaga ang pagtugon.