Why Does Spring Data Redis Cache Throw NullPointerException? A Deep Dive and Fix

Incident Scene

We first look at the exception stack.

java.lang.NullPointerException
	at org.springframework.data.redis.cache.RedisCache.get(RedisCache.java:180)
	at org.springframework.data.redis.cache.RedisCache.get(RedisCache.java:133)
	at org.springframework.cache.transaction.TransactionAwareCacheDecorator.get(TransactionAwareCacheDecorator.java:69)
	at org.springframework.cache.interceptor.AbstractCacheInvoker.doGet(AbstractCacheInvoker.java:71)
	at org.springframework.cache.interceptor.CacheAspectSupport.findInCaches(CacheAspectSupport.java:537)
	at org.springframework.cache.interceptor.CacheAspectSupport.findCachedItem(CacheAspectSupport.java:503)
	at org.springframework.cache.interceptor.CacheAspectSupport.execute(CacheAspectSupport.java:389)
	at org.springframework.cache.interceptor.CacheAspectSupport.execute(CacheAspectSupport.java:327)
	at org.springframework.cache.interceptor.CacheInterceptor.invoke(CacheInterceptor.java:61)

From the stack trace we can quickly locate the source code.

The exists call returns null, which leads to the NullPointerException.

Root Cause Analysis

Examining the relevant code reveals two places where return null can occur:

Boolean exists = (Boolean) redisOperations.execute(new RedisCallback<Boolean>() {
    @Override
    public Boolean doInRedis(RedisConnection connection) throws DataAccessException {
        return connection.exists(cacheKey.getKeyBytes());
    }
});

The execute method itself may return null when the underlying Redis operation fails.

Two typical reasons for such failure are:

Insufficient connections in the pool (blockWhenExhausted = true, maxWaitMillis exceeded).

Exceptions being swallowed in the catch block, causing a silent null return.

Reproducing the Issue

A minimal Spring Boot demo was created to reproduce the problem. Running the demo yields the same exception stack.

Debugging shows that the breakpoint never reaches the two return null statements, indicating that the failure occurs inside redisOperations.execute(). The custom RedisCustomTemplate (a subclass of RedisTemplate) is the entry point where the exception is caught and a null is returned.

How to Solve

Two main directions are recommended:

Connection‑pool tuning : Identify why the pool runs out of connections. Common causes include connection leaks, insufficient maxTotal settings, slow Redis responses, or network/DNS issues. Address the specific root cause rather than blindly increasing the pool size.

Custom RedisCache implementation : Extend RedisCache and override the method that returns null to handle the case safely, or upgrade to a newer library version where the bug is fixed.

Example of the problematic code:

if (!exists) {
    return null;
}

Problem Review

1. The art of questioning

Asking "Did anyone encounter this issue?" is less effective than stating the problem directly, which improves response rates.

2. Coding standards

Swallowing exceptions hides the real cause. The original exception is often a RedisConnectionFailureException:

org.springframework.data.redis.RedisConnectionFailureException: Cannot get Jedis connection;

nested exception is redis.clients.jedis.exceptions.JedisException: Could not get a resource from the pool

Printing the stack trace to System.out instead of a logger also loses valuable information.

3. Misleading naming

The class RedisCustomTemplate was named in a way that obscured its purpose, making debugging harder.

4. Exception output

Using ex.printStackTrace() or ex.getMessage() does not log the full stack. Proper logging frameworks should be used. synchronized usage was noted but is not a primary concern.

Key Takeaways

Check your own project's code for the above pitfalls.