Uma única instância Jedis não é threadsafe porque foi implementada dessa maneira. Essa é a decisão que o autor da biblioteca tomou.
Você pode verificar o código fonte de BinaryJedis que é um super tipo de Jedis https://github.com/xetorthio/jedis/blob/master/src/main/java/redis/clients/jedis/BinaryJedis.java
Por exemplo estas linhas:
public Transaction multi() {
client.multi();
client.getOne(); // expected OK
transaction = new Transaction(client);
return transaction;
}
Como você pode ver, o campo de transação é compartilhado para todos os threads usando a instância Jedis e inicializado neste método. Mais tarde esta transação pode ser usada em outros métodos. Imagine dois threads realizando operações transacionais ao mesmo tempo. O resultado pode ser que uma transação criada por um encadeamento seja acessada involuntariamente por outro encadeamento. O campo de transação neste caso é o acesso de estado compartilhado ao qual não está sincronizado. Isso torna os Jedis não threadsafe.
A razão pela qual o autor decidiu tornar o Jedis non-threadsafe e o JedisPool threadsafe pode ser fornecer flexibilidade para os clientes para que, se você tiver um ambiente de thread único, possa usar o Jedis e obter melhor desempenho ou, se tiver um ambiente multithread, poderá usar JedisPool e obtenha segurança de thread.
