Memory leak with pendingEvictionNotifications on compute method in ComputingConcurrentHashMap

[GoogleCodeExporter]

The javadoc for processPendingNotifications in CustomConcurrentHashMap says 
that "This should be called every time expireEntries or evictEntry is called 
(once the lock is released)."  

The compute method in ComputingConcurrentHashMap calls expire and evict but 
doesn't call processPendingNotifications after unlock.  

If you have a map that is computing and you only ever access it using get(), 
then things will pile up in the pendingEvictionNotifications queue and will 
stay retained in memory.

here is a unit test that fails that should succeed.

    public void testComputingExpire() throws Exception {
        final AtomicLong count = new AtomicLong();
        ConcurrentMap<Object, Object> map = new MapMaker().expireAfterAccess(1, TimeUnit.NANOSECONDS).evictionListener(new MapEvictionListener<Object, Object>() {
            public void onEviction(Object key, Object value) {
                count.incrementAndGet();
            }
        }).makeComputingMap(new Function<Object, Object>() {
            public Object apply(Object input) {
                return 0L;
            }
        });

        map.get(0);
        Thread.sleep(1);
        map.get(0);
        assertEquals(1, count.get());
    }

Original issue reported on code.google.com by john.car...@gmail.com on 18 Mar 2011 at 7:56

[GoogleCodeExporter]

This has been fixed in trunk, and will be part of the upcoming release 9.

Original comment by fry@google.com on 21 Mar 2011 at 2:47

• Changed state: Fixed
• Added labels: Milestone-Release09

[GoogleCodeExporter]

This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:15

• Added labels: MigratedToGitHub

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:09

• Added labels: Restrict-AddIssueComment-Commit