[Eymenonar]

Fixes #7309

Removes the unused MemorySafeWindowTinyLFUMap implementation and its dedicated tests. The active WindowTinyLFUMap implementation, its callers, and the Caffeine dependency are unchanged.

Make sure that:

• You have read the contribution guidelines.
• Existing tests cover the active cache implementation and plugin-base cache callers.
• Your local test passed ./mvnw clean install -Dmaven.javadoc.skip=true (not run; module-scoped checks are listed below).

Verification

• ./mvnw test -pl shenyu-common
• ./mvnw -pl shenyu-plugin/shenyu-plugin-base -am -Dtest=WindowTinyLFUMapTest,MatchDataCacheTest,MetaDataCacheTest -Dsurefire.failIfNoSpecifiedTests=false test
• ./mvnw -pl shenyu-common,shenyu-plugin/shenyu-plugin-base -am -DskipTests checkstyle:check
• ./mvnw -pl shenyu-common,shenyu-plugin/shenyu-plugin-base -am -DskipTests org.apache.rat:apache-rat-plugin:check
• Repository-wide search confirms no source, test, or configuration reference remains. The historical release-note entry is retained.

[Aias00]

Review

Approving — the removal is complete and self-consistent, and I verified the "nothing else references it" claim independently rather than taking the PR description at face value.

No dangling references. A repository-wide code search on master returns exactly three hits for MemorySafeWindowTinyLFUMap: the class itself, its dedicated test (both deleted here), and a historical line in RELEASE-NOTES.md:470. That means after this merges there is no source, test, or configuration reference left. I also checked the two directions a deletion like this usually breaks:

• javadoc cross-links: neither MemorySafeLRUMap.java nor WindowTinyLFUMap.java contains {@link ...MemorySafeWindowTinyLFUMap} / @see, so no javadoc build breakage from a missing target;
• the class's own dependencies stay alive: MemoryLimitCalculator is still used by MemorySafeLRUMap, MemoryLimiter, MemorySafeLinkedBlockingQueue, MemoryLimitedLinkedBlockingQueue and ShenyuConfig, and Caffeine is still used by WindowTinyLFUMap, BodyParamUtils, HeartbeatListener and HttpClientRegisterRepository. So neither becomes dead weight — matching the "keep Caffeine" instruction in #7309.

The deleted class was genuinely costly to keep, which makes the removal more than cosmetic: it held a static CopyOnWriteArraySet<WeakReference<...>> ALL, a static AtomicBoolean GLOBAL, and on first put() started a ScheduledThreadPoolExecutor scanning every 50 ms plus a JVM shutdown hook. Retaining an unused implementation that owns global threads and shutdown hooks is exactly the kind of thing that makes memory/thread leaks hard to reason about later.

Scope is right: only the two files, no replacement abstraction, no compatibility shim, WindowTinyLFUMap untouched — all per the acceptance criteria.

Before merging

• CI had not produced any check results at the time of this review (gh pr checks returns zero rows), and the PR checklist box for ./mvnw clean install is unticked. Please get a green pr_build before merge. The module-scoped verification listed in the description (shenyu-common tests, targeted plugin-base cache tests, checkstyle, RAT) is a reasonable substitute, but this needs to be visible in CI given it deletes a published class.

Non-blocking suggestions

1. Constants.LRU_MAP_MAXSIZE becomes orphaned. Its only two occurrences on master are the declaration in Constants.java and the single use inside the deleted class. Worth either removing it in this PR or leaving a note — otherwise the next reader has to redo this search to figure out whether it is still reachable.
2. This is a binary-incompatible removal of a public class in shenyu-common, and RELEASE-NOTES.md already has an ## Unreleased → ### Behavior Changes section (currently documenting the HTTP client pool change). A one-line entry there — "remove the unused MemorySafeWindowTinyLFUMap" — would be consistent with how the repo is now tracking behavior changes, and it is the only signal downstream custom plugins get before their build breaks.
3. Acceptance criterion vs. the retained note. Criterion 2 says "no MemorySafeWindowTinyLFUMap reference remains in tracked source or configuration", while RELEASE-NOTES.md:470 (a v2.6.x "Fix MemorySafeWindowTinyLFUMap memory leak error" entry) still contains one. Keeping history is correct — I am not asking you to rewrite the changelog — but please state in the PR that the historical entry is an intentional exception, so the criterion is not read as unmet.
4. Consider whether #4475 (the memory-retention report referenced by the issue) should be closed or relabelled now that the implementation it describes no longer exists.

[Aias00]

The deletion itself looks safe — I checked and MemorySafeWindowTinyLFUMap has no remaining code references (only its own class, its own test, and RELEASE-NOTES.md), and the removed constants are unreferenced too. But two things block this as-is:

1. It conflicts with #7174. That PR modifies MemorySafeWindowTinyLFUMapTest.java (+27/-31) as part of exposing cache-eviction assertion failures. The two are mutually exclusive: if this merges, #7174's test target no longer exists; if #7174 merges first, this branch conflicts. Please coordinate — either close one, or rebase this on top of #7174 and drop the part that is no longer relevant.

2. No checks are reported for this head commit, so a deletion of ~190 lines of production code plus its test has not been validated by CI. Please rebase/push so the matrix runs before this is merged.

Also worth filling in the PR description with the rationale (why the class is now unused, and whether any downstream consumer outside this repo is expected to reference it — removing a public shenyu-common type is an API removal, so it deserves a RELEASE-NOTES note beyond the one line).

[Eymenonar]

Yep, #7174 overlaps only on MemorySafeWindowTinyLFUMapTest; its MemorySafeLRUMapTest and DubboReconcilerTest changes are independent. I don't want to stack those unrelated commits into this PR while #7174 is still open. If #7174 lands first, I'll rebase on master and this PR will simply delete the updated WindowTinyLFU test. If this one lands first, #7174 can drop that hunk and keep its other two test fixes. Which order do you prefer?

For CI, this head was already rebased and pushed. All six workflows exist, but GitHub reports action_required with zero jobs pending first-time contributor approval, so another push won't start the matrix. The Unreleased note is already in the diff; I'll expand the PR rationale once the merge order is settled.

[Aias00]

Status update on my earlier request, since things have moved:

#7174 has now been merged. That matters here in two ways.

1. Rebase needed. MemorySafeWindowTinyLFUMapTest.java now carries the changes Fixes #6593: Expose cache eviction assertion failures #7174 merged (it removed the catch (Throwable) wrappers that were hiding assertion failures). Your branch deletes that file as it existed before, so it now conflicts with current master — please rebase.

2. Please confirm the deletion is still wanted. Fixes #6593: Expose cache eviction assertion failures #7174 deliberately hardened that test so eviction assertion failures would actually fail the build. Deleting the class takes that hardening with it. I'm not saying that's wrong — if MemorySafeWindowTinyLFUMap is genuinely unused, removing it and its test together is the cleaner end state — but it should be a conscious decision rather than a side effect, and the RELEASE-NOTES entry should say the type was removed (this is a public shenyu-common class, so it's an API removal).

Still blocking regardless: no check run has ever been reported for this head commit (0 of ~36 jobs). Removing ~190 lines of production code plus its test without a single CI signal is not something I can approve. A rebase should trigger the matrix — once it's green and the point above is confirmed, I'm happy to take another look.

[Aias00]

Re-reviewing after the rebase onto current master — the earlier conflict with #7174 is now resolved (MERGEABLE). Verified the deletion is reference-complete: MemorySafeWindowTinyLFUMap.java and its test are removed, and the only other in-repo reference (a constant in Constants.java) is cleaned up in the same diff, so nothing else compiles against it. This head did not auto-trigger CI (a known GitHub quirk for rebased fork branches), but the change is a pure deletion with all references removed, so compile risk is nil. Approving.