Vous confondez ici les verrous de base de données avec les verrous Java. JMC ne vous montre que les verrous à l'intérieur de votre programme Java (blocs synchronisés, attentes, etc.), il ne sait rien de ce qui se passe à l'intérieur de votre base de données. Votre requête SQL ne montre que les verrous au niveau de la base de données (verrous de table, verrous de ligne, etc.) et ne sait rien des verrous à l'intérieur de votre programme Java. Ce sont des zones absolument différentes et des serrures absolument différentes.
Ce que vous avez ici est un vidage d'un thread qui détient un verrou sur l'objet de type T4CConnection avec l'adresse 0x7af3423c0 . Cela signifie seulement que ce thread est en train d'exécuter un code à l'intérieur d'une synchronized(connection) bloquer. C'est tout. Le thread n'est pas bloqué par d'autres threads (sinon son état ne serait pas RUNNABLE , ce serait WAITING ou BLOCKED ). Il s'exécute et lit quelque chose à partir d'un socket réseau (probablement la réponse de la base de données).
Un tel comportement est tout à fait normal. Le pilote de base de données effectue une synchronisation sur l'instance de connexion pendant qu'il est en train d'exécuter une requête SQL pour ne pas permettre à d'autres threads de l'utiliser en parallèle.
Il n'y a rien dont vous devriez vous inquiéter sur cette capture d'écran et dans ce vidage de fil.
