Heureusement, les derniers JDK proposent des outils plus ou moins ergonomiques afin de surveiller et mieux comprendre ce qu’il se passe. Avant toute chose, voici un (très) bref rappel du fonctionnement de la gestion de la mémoire Java et de son « garbage collector » (ou GC).

Java et le « garbage collector »

Afin d’optimiser le fonctionnement du GC, Java utilise par défaut un système mettant en oeuvre plusieurs zones mémoire. Ces zones sont utilisées par les objets plus ou moins vieux. Je ne rentrerai pas dans les détails de ces zones ni comment les dimensionner. Le GC utilise 3 zones au fur et à mesure que les objets vieillisent :

- Survivor space : Il est en fait séparé en 2. Chaque zone est active alternativement. Les objets nouvellement créés sont créés dans la zone active. Au moment du passage du YGC (Young Garbage Collector), celui-ci va nettoyer le Survivor Space en recopiant les objets encore référencés dans la seconde zone qui devient active à son tour. Au bout d’un certain nombre d’allez-retour, les objets sont alors transférés dans le « Eden space ».

- Young Space : Comme nous venons de le voir cette zone reçoit les objets encore jeunes qui ont survécus à plusieurs YGC.

- Old Space : Lorsque la place vient à manquer dans le Young Space, un Full Garbage Collector (FGC) est lancé et les objets les plus anciens de la Young Zone sont transférés dans cette zone.

En plus de ces 3 zones, il existe le Permanent Space qui comme son nom l’indique est utilisé pour le cache du code et les objets statiques.

Lorsqu’un problème de mémoire arrive, c’est en général car des objets restent référencés (par une liste ou autre) et finissent donc par remplir le Old Space. Un des premiers outils bien pratique pour suivre ces mouvements de mémoire entre les zones est jstat qui est livré avec le JDK. Différentes options existent, mais la surveillance du Garbage Collector est sans doute le plus intéressant dans notre cas.

jstat -gc -h10 <pid> 5s

 S0C    S1C    S0U    S1U      EC       EU        OC         OU       PC     PU    YGC     YGCT    FGC    FGCT     GCT
5376.0 10944.0 5319.5  0.0   723712.0 393938.3  571776.0   548046.1  61568.0 58080.5    754   27.767  26     16.290   44.057
9600.0 6976.0  0.0   6964.5 691648.0 232030.5  571776.0   550188.2  61568.0 58084.8    755   27.801  26     16.290   44.091
5504.0 10560.0 5465.1  0.0   777088.0 106216.4  571776.0   553407.3  61568.0 58085.2    756   27.870  26     16.290   44.161
5504.0 10560.0 5465.1  0.0   777088.0 608730.8  571776.0   553407.3  61568.0 58085.7    756   27.870  26     16.290   44.161
9856.0 5824.0  0.0   5801.2 865984.0 263527.0  571776.0   555880.7  61568.0 58086.1    757   27.892  26     16.290   44.182
9856.0 5824.0  0.0   5801.2 865984.0 696381.0  571776.0   555880.7  61568.0 58088.1    757   27.892  26     16.290   44.182
8192.0 10496.0 8180.9  0.0   826944.0 359223.6  571776.0   558621.8  61568.0 58088.4    758   27.910  26     16.290   44.201
7552.0 5312.0  0.0   5296.1 789824.0 71320.0   571776.0   563405.1  61568.0 58088.9    759   27.963  26     16.290   44.253
7552.0 5312.0  0.0   5296.1 789824.0 648105.7  571776.0   563405.1  61568.0 58090.4    759   27.963  26     16.290   44.253
6464.0 10176.0 6452.6  0.0   880512.0 401761.5  571776.0   565630.1  61568.0 58090.4    760   28.016  26     16.290   44.306
 S0C    S1C    S0U    S1U      EC       EU        OC         OU       PC     PU    YGC     YGCT    FGC    FGCT     GCT
6464.0 10176.0 6452.6  0.0   880512.0 876197.9  571776.0   565630.1  61568.0 58093.7    760   28.016  26     16.290   44.306
9024.0 4928.0  0.0    0.0   840704.0 321404.4  567360.0   469081.9  61440.0 58096.0    761   28.034  27     17.329   45.363

Voici quelques explication sur la signification des entêtes de colonne concernant les zones :

- La première lettre indique la zone : S0 et S1 = survivor 1 et 2, E = Eden, O = Old et P = Permanent

- La dernière lettre indique la mémoire réellement occupée ou la taille réservée : C = Capacity et U = Used

Concernant le GC : YGC = Young GC, YGCT = Young GC Time, FGC = Full GC, FGCT = Full GC Time et GCT = GC Time (temps global)

On voit tout d’abord, que S0 et S1 sont remplis l’un ou l’autre mais pas les deux en même temps. En regardant la colonne YGC, on voit qu’a chaque incrémentation, S0 et S1 permuttent. La taille de l’Eden Space varie également à chaque passage du YGC. On voit également qu’à chaque YGC, le OU augmente afin de stocker les objets les plus anciens de l’Eden Space. Enfin on voit qu’à l’avant dernière ligne, le OU se rapporchait du OC ce qui laissait présager de la saturation de la zone Old Space. La dernière ligne indique donc le passage du FGC qui a eu pour effet de nettoyer le Old Space et de lui réassigner une nouvelle taille.

Que se passe-t-il en cas de fuite mémoire (autrement dit d’objets restant alloués par erreur) ? Le OC grossit de plus en plus, une fois arrivé à son max, le OU se rapproche de la limite. Le FGC passe donc fréquemment au point de ralentir la JVM… puis une belle exception OutOfMemory est déclenchée.

Analyse d’une JVM

Jstat vous permet d’observer l’occupation mémoire, et voir que vous avez effectivement un problème… Mais comment savoir d’où ça vient ? Il existe plusieurs outils, je vous citerai les 2 que j’utilise : jmap et mat.

Jmap est un outil du même style que jstat. Il est livré avec le JDK et permet d’analyser une JVM en cours de fonctionnement. Il permet dans un premier temps d’obtenir une liste des objets actuellement en mémoire, triée par occupation mémoire décroissante. Bien entendu les premières places sont occupées par des objets comme String, byte[], etc, mais si vous voyez une de vos classes dans les 20 premières positions… c’est louche. Pour obtenir cette liste, voici la commande :

jmap -histo <pid>

Si cette liste ne suffit pas à trouver le fautif, vous pouvez utiliser l’artillerie lourde : générer un dump binaire et utiliser un outil qui analysera ce dump vous permettant de naviguer dans vos objets en mémoire. Un dump peut être généré de différentes façons (par exemple jmap ou jconsole). Voici la commande jmap qui génère ce dump :

jmap -heap:format=b

Cette commande correspond à un JDK5 et peut être différente avec un JDK d’une autre version. Attention, si la génération de la liste ne prend que quelques secondes, la génération d’un dump est beaucoup plus longue. Inutile de vous dire que pendant ce temps la JVM est bloquée… donc pour une JVM en exploitation, il vaut mieux le savoir

Différents outils d’analyse existent également. J’utilise pour ma part MAT qui est un plugin Eclipse et existe également dans version autonome. Cette dernière est préférable pour des question d’occupation mémoire (il faut beaucoup de mémoire pour analyser le dump). Cet outil permet d’analyser le dump et de vous suggérer des problèmes possibles. Si cela ne suffit pas (ou si vous pensez qu’il se trompe) vous pourrez alors analyser les objets, trouver leur référence, voir leur contenu, etc.

Spring met à votre disposition 2 dispositifs rendant l’utilisation de JMS très simple :

- JmsTemplate : gère la connexion vers le serveur déclaré et l’envoi des données

- SimpleMessageListenerContainer : assure la réception des messages et l’appel à votre classe en charge de traiter la réception des objets.

1ère étape : déclaration du serveur

Dans un fichier xml de configuration Spring, insérez ces lignes (dans notre exemple, il s’agit de la déclaration des 2 serveurs ActiveMQ locaux) :

    <!-- ActiveMQ Sender -->
    <bean id="connectionFactorySender" class="org.apache.activemq.ActiveMQConnectionFactory">
        <property name="brokerURL" value="tcp://localhost:61616"/>
    </bean>

    <!-- ActiveMQ Receiver -->
    <bean id="connectionFactoryListener" class="org.apache.activemq.ActiveMQConnectionFactory">
        <property name="brokerURL" value="tcp://localhost:61616"/>
    </bean>

ainsi que la déclaration de la queue qui sera utilisée pour nos échanges de messages :

    <bean id="categs_backup_queue" class="org.apache.activemq.command.ActiveMQQueue">
        <constructor-arg value="categs_backup"/>
    </bean>

2ème étape : gestion de l’émission des messages

Dans notre exemple, nous échangerons des POJOs représentants des catégories afin de les sauvegarder sur un autre serveur.

Voici l’implémentation de la classe servant à envoyer ces messages :

public class CategorieBackupSenderImpl implements CategorieBackupSender {
    private JmsTemplate jmsTemplate;
    private Queue queue;

    @Required
    public void setConnectionFactory(ConnectionFactory cf) {
        this.jmsTemplate = new JmsTemplate(cf);
    }

    @Required
    public void setQueue(Queue queue) {
        this.queue = queue;
    }

    /* (non-Javadoc)
     * @see com.bp.jms.CategorieBackupSender#simpleSend()
     */
    public void send(final Categorie categ) {
        this.jmsTemplate.send(this.queue, new MessageCreator() {
            public ObjectMessage createMessage(Session session) throws JMSException {
              return (ObjectMessage) session.createObjectMessage(categ);
            }
        });
    }
}

Les deux setters servent à Spring pour renseigner les propriétés nécessaires au bon fonctionnement de cette classe : le template (JmsTemplate) qui utilise la connexion au serveur JMS (ConnectionFactory) et la queue (Queue).

La méthode Send fait appel au template pour créer le message à partir de notre POJO via la classe MessageCreator.

Il nous reste à déclarer ce composant dans le XML de configuration Spring :

    <bean id="categorieBackupSender" class="com.bp.categories.jms.impl.CategorieBackupSenderImpl">
        <property name="connectionFactory" ref="connectionFactorySender"/>
        <property name="queue" ref="categs_backup_queue"/>
    </bean>

C’est tout pour l’émission des messages ! La bonne nouvelle c’est que la réception n’est guère plus compliquée

3è étape : gestion de la réception des messages

Voici la classe gérant cette réception :

public class CategorieBackupListener implements MessageListener {

    private CategorieService categorieService;

    /**
     * @param categorieService the categorieService to set
     */
    @Required
    public void setCategorieService(CategorieService categorieService) {
        this.categorieService = categorieService;
    }

    public void onMessage(Message message) {
        if (message instanceof ObjectMessage) {
            try {
                Categorie categ = (Categorie) ((ObjectMessage) message).getObject();
                categorieService.backup(categ);
            }
            catch (JMSException ex) {
                throw new RuntimeException(ex);
            }
        }
        else {
            throw new IllegalArgumentException("Message must be of type ObjectMessage");
        }
    }
}

Le source est assez parlant de lui-même. Suite à la réception du message, le service CategorieService est appelé afin d’effectuer le traitement approprié.

De même que pour l’émission, la configuration Spring est importante…

    <bean id="categorieBackupListener" class="com.bp.categories.jms.CategorieBackupListener">
        <property name="categorieService" ref="categorieService" />
    </bean>

    <bean id="listener" class="org.springframework.jms.listener.SimpleMessageListenerContainer">
       <property name="connectionFactory" ref="connectionFactoryListener"/>
       <property name="destination" ref="categs_backup_queue"/>
       <property name="concurrentConsumers" value="3"/>
       <property name="messageListener" ref="categorieBackupListener"/>
    </bean>

Bien entendu dans cet exemple nous échangeons des POJOs reconnus par JMS comme simple Object. Il est possible d’améliorer tout ça, ne serait-ce que pour s’assurer que l’objet reçu est bien l’objet attendu ou aussi pour échanger des objets de différents types en utilisant la même queue.

4ème étape : fonctionnement de notre exemple

Nous devons déclarer nos deux beans :

        categorieService = (CategorieService) Context.getContext().getBean("categorieService");
        categorieBackupSender = (CategorieBackupSender) Context.getContext().getBean("categorieBackupSender");

puis la récupération de nos objets et leur envoi :

        List<Categorie> categs = categorieService.getCategs();
        if (categs != null) {
            for (Categorie categ: categs) {
                categorieBackupSender.send(categ);
            }
        }

La réception se met en route automatique dès l’instanciation du listener.

Si vous voulez contrôler le fonctionnement du listener, alors il faut déclarer un troisième bean :

        listener = ((SimpleMessageListenerContainer) Context.getContext().getBean("listener"));

Voilà, cet exemple ne présente sans doute pas toutes les possibilités que l’on peut faire de JMS avec Spring, mais c’est un bon début

-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=<port>
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false

Comme vous l’aurez constaté, il n’y a aucune sécurité d’accès et cela n’est conseillé que pour un serveur présent sur un réseau protégé. Dans certain cas, il est nécessaire d’ajouter :

-Djava.rmi.server.hostname=<IP qui doit écouter sur le port JMX>

Suivant la façon de lancer Tomcat, vous pourrez insérer ces propriétés das le script de démarrage ou dans la variable d’environnement JAVA_OPTS qui est lue par les scripts Tomcat. Il ne vous restera plus qu’à vous connecter avec JConsole sur l’ip et le port indiqué et à scruter toutes les informations délivrées.