Skip to content

fix(cache): init guard, corrupted entry eviction, and lock improvement#1925

Merged
openai0229 merged 6 commits into
OtterMind:mainfrom
HandSonic:fix/cache-fixes
Jul 24, 2026
Merged

fix(cache): init guard, corrupted entry eviction, and lock improvement#1925
openai0229 merged 6 commits into
OtterMind:mainfrom
HandSonic:fix/cache-fixes

Conversation

@HandSonic

Copy link
Copy Markdown
Contributor

Summary

Fixes 3 verified bugs in the cache layer.

Fixes included:

  • CacheManage.fuzzyDelete(): added if (!init) return; guard to prevent NPE when static initialization failed
  • CacheManage.getList(): evicts corrupted cache entries on deserialization failure instead of letting them persist until TTL
  • MemoryCacheManage: replaced String.intern() locking with ConcurrentHashMap to prevent JVM string pool pollution

- fuzzyDelete() now checks init flag before accessing cacheManager,
  preventing NPE when static initialization failed
- getList() now removes corrupted cache entries on deserialization failure,
  preventing repeated parse errors until TTL expires
String.intern() uses the JVM global string pool which is never GC'd,
causing memory leaks in long-running deployments. ConcurrentHashMap
provides the same per-key locking without polluting the string pool.

@openai0229 openai0229 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The corrupted-entry eviction and initialization guard look reasonable, but the lock change still introduces unbounded permanent retention. LOCK_MAP.computeIfAbsent(lockKey, ...) adds one entry per distinct key and no path ever removes it, so this replaces string-intern retention with another process-lifetime map leak.

Please use a bounded striped-lock implementation, or implement lifecycle-safe removal that cannot remove a lock while another thread is waiting on or using it. Add a concurrency test that covers many distinct keys and same-key mutual exclusion. Also coordinate the duplicated fuzzyDelete guard with #1890 so only one focused change remains.

# Conflicts:
#	chat2db-community-server/chat2db-community-domain/chat2db-community-domain-core/src/main/java/ai/chat2db/community/domain/core/cache/CacheManage.java

@openai0229 openai0229 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed and updated. The superseded CacheManage changes were dropped in favor of current main. The remaining lock fix now uses a bounded 1,024-stripe Guava lock set instead of an unbounded map, with tests covering many distinct keys and same-key mutual exclusion. Targeted domain-core tests pass locally.

@openai0229
openai0229 merged commit 428a513 into OtterMind:main Jul 24, 2026
16 checks passed
@openai0229 openai0229 moved this to Done in Chat2DB Community Jul 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

2 participants