Pourquoi une seule instance Jedis n'est pas thread-safe ?

Une seule instance de Jedis n'est pas thread-safe car elle a été implémentée de cette façon. C'est la décision que l'auteur de la bibliothèque a prise.

Vous pouvez vérifier le code source de BinaryJedis qui est un super type de Jedis https://github.com/xetorthio/jedis/blob/master/src/main/java/redis/clients/jedis/BinaryJedis.java

Par exemple ces lignes :

public Transaction multi() {
    client.multi();
    client.getOne(); // expected OK
    transaction = new Transaction(client);
    return transaction;
}

Comme vous pouvez le voir, le champ de transaction est partagé pour tous les threads utilisant l'instance Jedis et initialisé dans cette méthode. Plus tard, cette transaction peut être utilisée dans d'autres méthodes. Imaginez que deux threads effectuent des opérations transactionnelles en même temps. Le résultat peut être qu'une transaction créée par un thread est involontairement accédée par un autre thread. Le champ de transaction dans ce cas est un accès d'état partagé auquel n'est pas synchronisé. Cela rend Jedis non thread-safe.

La raison pour laquelle l'auteur a décidé de rendre Jedis non-threadsafe et JedisPool threadsafe pourrait être de fournir de la flexibilité aux clients afin que si vous avez un environnement à un seul thread, vous puissiez utiliser Jedis et obtenir de meilleures performances ou si vous avez un environnement multithread, vous pouvez utiliser JedisPool et bénéficiez de la sécurité des threads.