Uncovering Jedis Socket Memory Leaks: How Pool Eviction Triggers GC Overhead

Background

In a fleet of N machines, one server gradually exhibits a socket memory leak, visible in jmap output where classes like java.net.SocksSocketImpl, java.net.SocketInputStream, and java.net.SocketOutputStream rank high in memory usage.

STEP0

The problematic machine runs a periodic data‑processing task every five minutes, lasting about a minute, causing its Young Generation GC (YGC) to trigger roughly every ten seconds, compared to about one minute on other machines.

STEP1

Using BTrace (or similar instrumentation), the stack trace for frequent java.net.SocketInputStream construction was captured, showing a chain that originates from Jedis connection creation via redis.clients.jedis.Connection.connect and ultimately the Commons‑Pool object pool.

thread=["0x6c", "commons-pool-EvictionTimer"]
java.net.SocketInputStream.<init>(SocketInputStream.java:61)
    at java.net.AbstractPlainSocketImpl.getInputStream(AbstractPlainSocketImpl.java:425)
    at java.net.Socket$2.run(Socket.java:914)
    ...
    at redis.clients.jedis.Connection.connect(Connection.java:204)
    at redis.clients.jedis.BinaryClient.connect(BinaryClient.java:93)
    at redis.clients.jedis.BinaryJedis.connect(BinaryJedis.java:1767)
    at redis.clients.jedis.JedisFactory.makeObject(JedisFactory.java:106)
    at org.apache.commons.pool2.impl.GenericObjectPool.create(GenericObjectPool.java:868)
    ...

The trace makes it clear that the Commons‑Pool component of Jedis is repeatedly creating socket objects.

STEP2

The creation originates from org.apache.commons.pool2.impl.GenericObjectPool.ensureIdle, which invokes create when the idle object pool is insufficient.

STEP3

JedisPoolConfig sets setTimeBetweenEvictionRunsMillis(30000), meaning the pool runs an eviction task every 30 seconds. The default eviction policy evicts idle objects that have been idle for more than one minute (if total idle > minIdle) or more than 30 minutes, forcing the pool to create new socket connections repeatedly.

evict = evictionPolicy.evict(evictionConfig, underTest, idleObjects.size());

This aggressive eviction explains the continuous socket creation observed in STEP1 and STEP2.

STEP4

JMap also shows a large number of java.lang.ref.Finalizer instances, matching the leaked socket count. The java.net.AbstractPlainSocketImpl#finalize method calls close() to clean up forgotten sockets, but the finalizer queue processes objects slower than the pool creates them.

protected void finalize() throws IOException { close(); }

Consequently, sockets linger in the finalizer queue, delaying reclamation and exacerbating the leak.

Additional Findings

The periodic task increases YGC frequency on the affected machine.

Commons‑Pool eviction continuously creates new sockets, further raising YGC pressure.

Socket finalizers add latency to object reclamation.

The configured minIdle value (150) is too high, causing the pool to frequently fall below the threshold after eviction and trigger more creations.

Conclusion

Even seemingly minor configuration issues—such as aggressive eviction intervals and oversized minIdle settings—can combine with Java finalizer behavior to produce noticeable socket memory leaks and GC overhead.