[BUG] MetaDataCache: unbounded CACHE (maximumSize=Integer.MAX_VALUE) + MAPPING Set never shrunk #6565

Description

CACHE is a WindowTinyLFUMap built with maximumSize = Integer.MAX_VALUE, which disables size-based eviction entirely; there is no expireAfterWrite. The class comment at line 148 even acknowledges OOM risk yet configures an unbounded size. MAPPING (ConcurrentMap<String, Set<String>>) is populated by initCache: for wildcard metadata paths the reverse-mapping ConcurrentSkipListSet under each metaPath collects every distinct request path ever matched. clean(key) removes CACHE entries but never clears the Set itself and never removes it from MAPPING; remove(MetaData) only calls clean(path).

Location

shenyu-plugin-base/.../cache/MetaDataCache.java:48 (CACHE), 53 (MAPPING), 99-107 (clean), 147-157 (initCache)

Impact

MetaDataCache.obtain(path) is called every request from the global plugin and divide/context-path/rewrite plugins. High-cardinality request paths (e.g. /api/users/{userId} with millions of distinct IDs) cause monotonic, unbounded heap growth in both CACHE and the MAPPING ConcurrentSkipListSet (memory-heavy per entry) that survives metadata refreshes. Slow OOM over days/weeks for public-facing REST gateways.

Suggested fix

Set a real configurable maximumSize and expireAfterAccess; in clean(key), after removing CACHE entries, also MAPPING.get(key).clear() and MAPPING.remove(key).

Related existing issue(s)

#6506 is the CachePlugin (response caching); this is the metadata path cache. #6479 is discovery-upstream cache staleness; this is selector/metadata cache growth.

Identified during the 2026-08-02 audit; full list in docs/issue-candidates-2026-08-02.md.