Eine einzelne Jedis-Instanz ist nicht threadsicher, da sie auf diese Weise implementiert wurde. Das ist die Entscheidung, die der Autor der Bibliothek getroffen hat.
Sie können den Quellcode von BinaryJedis, einem Supertyp von Jedis, einsehen https://github.com/xetorthio/jedis/blob/master/src/main/java/redis/clients/jedis/BinaryJedis.java
Zum Beispiel diese Zeilen:
public Transaction multi() {
client.multi();
client.getOne(); // expected OK
transaction = new Transaction(client);
return transaction;
}
Wie Sie sehen können, wird das Transaktionsfeld für alle Threads geteilt, die die Jedis-Instanz verwenden, und in dieser Methode initialisiert. Später kann diese Transaktion in anderen Methoden verwendet werden. Stellen Sie sich vor, zwei Threads führen gleichzeitig Transaktionsoperationen aus. Das Ergebnis kann sein, dass auf eine Transaktion, die von einem Thread erstellt wurde, unbeabsichtigt von einem anderen Thread zugegriffen wird. Das Transaktionsfeld ist in diesem Fall ein gemeinsamer Zustandszugriff, auf den nicht synchronisiert wird. Das macht Jedis nicht-threadsicher.
Der Grund, warum der Autor entschieden hat, Jedis non-threadsafe und JedisPool threadsicher zu machen, könnte darin bestehen, Clients Flexibilität zu bieten, sodass Sie Jedis verwenden können, wenn Sie eine Single-Thread-Umgebung haben und eine bessere Leistung haben, oder wenn Sie eine Multithread-Umgebung haben, die Sie verwenden können JedisPool und sichere Threads.
