Blog

Dans un service Spring Boot rangé par couches techniques (controller, service, repository, entity…), la règle métier finit à côté du code JPA, Kafka et Jackson. Pour la tester, il faut démarrer Spring, ou simuler une bonne partie du framework. Cet article montre une autre organisation, l’architecture hexagonale, sur un petit exemple complet : un service qui lit des mesures de capteurs dans Kafka, les vérifie et calcule des statistiques. Le domaine et les cas d’usage sont en Java pur, Spring, Kafka et JPA restent dans des adaptateurs, et un test fait échouer le build si cette règle n’est pas respectée. Le code est dans le tag phase-1 du dépôt public iot-monitoring-platform, présenté dans l’article Kafka et Spring Boot : un projet complet en local. ...

Un service reçoit les mesures de capteurs, un autre doit les traiter et les stocker. Si le premier appelle le second en REST, les deux sont liés : quand le second est arrêté ou lent, le premier ne peut plus rien livrer. Kafka se place entre les deux : le premier publie un message, le second le lit à son rythme. Cet article monte ce lien de bout en bout, en local : Kafka en mode KRaft dans Docker, un service Spring Boot qui publie une simple ligne de texte, un autre qui la lit, et une page qui affiche la partition et l’offset de chaque message. Tout le code est dans le tag phase-1 du dépôt public iot-monitoring-platform. ...

Mon code Java range des fichiers dans S3 et des données dans DynamoDB. Comment le développer et l’essayer sur ma machine, sans compte AWS, sans facture, et sans changer le code qui parle à AWS ? Cet article présente Floci, un émulateur AWS local, avec un exemple de bout en bout : l’AWS CLI crée les ressources, une petite application Java les utilise, et la console web de Floci les montre. Je contribue au projet Floci. ...

Un développeur Java travaille souvent sur plusieurs stacks à la fois : un projet legacy en Java 8, un service en 17, un nouveau projet en 25. Maven ici, Gradle là. Node pour une doc, Python pour MkDocs. Et autour, des outils : aws, gh, kubectl, helm. Chaque SDK et chaque outil arrive avec son installeur. Peu à peu, le poste se remplit : des versions globales qui se mélangent, des sudo, un .zshrc rempli par les installeurs, une variable AWS restée en global. Ma question : comment avoir la bonne version de chaque SDK et de chaque outil dans chaque projet, sans rien installer en root, avec un seul outil, et un terminal qui reste rapide ? ...

Le pod redémarre. kubectl get pod affiche OOMKilled, le code de sortie est 137. Pourtant, les logs ne montrent aucune OutOfMemoryError, et le heap était loin d’être plein. Ce n’est pas la JVM qui a manqué de mémoire : c’est le conteneur. Le noyau Linux a tué le processus parce qu’il a dépassé sa limite. Cet article montre ce que la JVM voit dans un conteneur, ce qui s’ajoute au heap, comment reproduire le kill, et comment régler la mémoire pour que tout tienne. Tous les exemples sont dans le dossier containers/ du dépôt public java-gc-lab. Ils utilisent les images officielles eclipse-temurin : pas d’image à construire. ...

Dans cette série, on a déjà utilisé une demi-douzaine d’outils : les logs du GC, jstat, plusieurs commandes jcmd, Eclipse MAT. Chacun répond à une question précise, et chacun a un coût. Cet article les range, puis montre JFR, l’outil le plus complet du JDK, sur un exemple : trouver la méthode qui crée des millions d’objets. Quel outil pour quelle question Question Outil Commande Coût Le GC fait-il des pauses longues ? Le heap après GC monte-t-il ? Logs du GC -Xlog:gc*:file=gc.log à garder en production Quelle zone se remplit, en direct ? jstat jstat -gcutil <pid> 1s non indiqué ; « expérimental et non supporté » d’après sa doc Combien de heap est utilisé ? jcmd jcmd <pid> GC.heap_info moyen Quelle classe grossit ? jcmd jcmd <pid> GC.class_histogram élevé : lance un Full GC Qui retient les objets ? heap dump + Eclipse MAT jcmd <pid> GC.heap_dump élevé : un gros fichier Le Metaspace grossit-il ? jcmd jcmd <pid> VM.metaspace moyen Que fait la mémoire native ? jcmd + NMT -XX:NativeMemoryTracking=summary, puis jcmd <pid> VM.native_memory moyen Que font les threads ? jcmd jcmd <pid> Thread.print moyen Quelle méthode alloue, où sont les pauses, dans le temps ? JFR -XX:StartFlightRecording, puis jfr view faible avec la configuration default Le coût « moyen » ou « élevé » des commandes jcmd est celui qu’indique leur documentation. Chacun de ces outils a déjà servi dans un article : les logs du GC, les OutOfMemoryError, les fuites mémoire et le heap dump avec Eclipse MAT. ...

Dans l’article sur les fuites mémoire, deux histogrammes de jcmd montraient quelle classe grossit. Mais pas qui la retient. Pour ça, il faut un heap dump : une photo de tout le heap, avec les objets et les liens entre eux. On reprend la même fuite : UnboundedCache.java, un cache HashMap statique qui reçoit une nouvelle clé à chaque requête. On l’analyse avec Eclipse Memory Analyzer (MAT), un outil open source que le guide d’Oracle cite pour analyser les heap dumps. Toutes les commandes sont dans le dossier heap-dump du dépôt java-gc-lab. ...

En Java, le garbage collector libère les objets que plus rien ne référence. Une fuite mémoire, c’est donc un objet devenu inutile mais encore référencé : le GC ne peut pas le libérer. Le guide d’Oracle le dit ainsi : l’application garde des références à des objets « sans le vouloir ». Voici six fuites classiques, chacune reproduite par un petit programme du dépôt public java-gc-lab, avec ce qu’on voit et la correction. ...

Activer le log du GC est facile. Le lire l’est moins : une ligne de G1 contient une dizaine d’informations, et les mots changent d’une version de Java à l’autre. Cet article lit de vraies lignes, produites par trois petits programmes du dépôt public java-gc-lab : une charge normale, des objets très gros, et un heap presque plein. Activer le log java -Xlog:gc*:file=gc.log:time,uptime,level,tags -jar app.jar gc* : tous les messages du GC (gc seul donne une ligne par GC) ; file=gc.log : dans un fichier, avec une rotation déjà intégrée (5 fichiers d’environ 20 Mo par défaut) ; time,uptime,level,tags : les « décorations » au début de chaque ligne : la date et l’heure, le temps depuis le démarrage de la JVM, le niveau et les tags. Sans rien préciser, la JVM met uptime, level et tags. Une ligne de pause, avec ces décorations : ...

Une OutOfMemoryError, ce n’est pas un seul problème. Le texte après les deux-points dit quelle zone de la mémoire est pleine : le heap, le Metaspace, la mémoire directe ou les threads. Et chaque zone se vérifie et se corrige autrement. Pour chaque message, j’ai écrit un petit programme qui le provoque. Ils sont dans le dépôt public java-gc-lab, un fichier par message, à lancer avec java sans compiler (Java 11 ou plus). ...