Un service redémarre tous les deux ou trois jours avec une OutOfMemoryError. Comment trouvez-vous la cause ?

Lisez d'abord le message, puisque heap space, metaspace, direct buffer et GC overhead limit exceeded pointent vers des causes très différentes. Exécutez avec le dump du tas à la sortie mémoire pour capturer l'état au moment de l'échec, puis ouvrez le dump dans un analyseur de mémoire et regardez l'arbre de dominateurs pour voir ce qui retient le plus. Comparez des dumps dans le temps pour distinguer une vraie fuite d'un jeu de travail simplement plus grand que le tas.

La variante compte. Java heap space veut dire que des objets vivants remplissent vraiment le tas, metaspace veut dire que des classes sont chargées et jamais libérées, et une erreur de direct buffer pointe vers NIO ou une bibliothèque native plutôt que vers mes objets. Donc je lis ça en premier, puis je m'assure que la JVM tourne avec le dump du tas à la sortie mémoire et un chemin sur un volume qui survit au redémarrage, parce que deviner sans dump fait perdre des jours. Avec le dump je regarde la taille retenue plutôt que la taille superficielle, et l'arbre de dominateurs nomme en général le coupable en deux minutes. Ce que je trouve en pratique est répétitif : une map utilisée comme cache sans éviction, une ThreadLocal posée sur un thread de pool et jamais nettoyée donc elle vit aussi longtemps que le pool, ou une méthode de repository qui renvoie toutes les lignes parce que quelqu'un a supprimé la pagination. Je regarde aussi les logs du ramasse-miettes pour voir si le tas montait régulièrement ou s'il piquait sur certaines requêtes. Le correctif consiste à borner quelque chose, un cache avec une taille maximale et une expiration, ou une requête en flux, puis je surveille le jeu vivant sur une semaine pour confirmer qu'il est plat.