Nem. Az oomkiller nem a barátod. Utolsó utáni védvonal, rengeteg durva kompromisszummal. Olyan, mint az automata elárasztásos tűzoltórendszer. Nem ég porig a ház, de ami berendezést a tűz nem tett tönkre, azt tönkreteszi a víz.
Én úgy érzem, hogy itt az a probléma, hogy valójában az a bizonyos java-s service nincs jól üzemeltetve. Az üzemeltetőnek lenne dolga, hogy bemonitorozza rendszert, gyűjtse az adatokat. Felkonfigurálja a futtatókörnyezetnek megfelelően a JVM heap size paramétereit (a java-nál megadatott az üzemeltetőnek az a "luxus", hogy már runtime szinten tudja korlátozni a memóriát). Bekapcsoljon JMX-et, gyűjtse hogy mi történik a memóriával, mit csinál a GC. Összeszedje a szűkséges parancsokat - ad absurdum akár automatizálja - heap és stack dump készítéshez ha baj van, vagy akárcsak "baj közeli állapot" áll elő.
Ha a java-s service prodban bármi miatt leáll, akkor az üzemeltető dolga, hogy kiszedje belőle azt a debug infót, amit a fejlesztőknek oda tud adni a bug ticketben. Már csak azért is, mert normális helyen compliance miatt csak az üzemeltetőnek szabad, hogy egyáltalán hozzáférése legyen a prod rendszerhez. Ezt a munkát nem akkor kell elvégezni, amikor éppen az éjszaka közepén bejön az alert, hanem normál munkaidőben, megelőző jelleggel. Ez egy befektetés, ami az éjszaka közepén térül meg. Meg, amikor nem kell kötbért fizetned az ügyfélnek az outage miatt. Sok esetben a monitoring rendszerben már bőven azelőtt látszik a baj (pl memory leak), hogy a tényleges outage megtörténne.