## Unbounded Collection Growth (Medium)

### Trigger Signals

- Global/static Map/List/Set/Dict only has `put`/`add`/`set`/`push` without `remove`/`delete`/`evict`
- Cache implementation without size limit (no max size, max entries, max memory configuration)
- Log/history record collections only append without cleanup
- Map/Set with objects as keys (object references cannot be garbage collected)

### Judgment Process

1. **Identify growing collections**: `find_references` tracks global/static/class-member level collection variables, checking whether there are delete operations:
   - `Grep` searches for `delete`/`remove`/`clear`/`evict` calls on collection variables
   - Only `set`/`add`/`push`/`put` → potential unbounded growth
2. **Check growth rate**: `Read` confirms write frequency:
   - Written per request → high risk (rapid growth)
   - Written only at startup/config change → low risk
3. **Check eviction strategy**: `Read` confirms whether the following exist:
   - Size limit (`if (cache.size > MAX) { cache.clear() }`)
   - TTL/expiration cleanup (`setTimeout` periodic cleanup, LRU strategy)
   - Using LRU/TTL libraries (`lru-cache`, `Guava Cache`, `TTLMap`)
4. **Check object key references**: `Read` confirms whether Map/Set keys are object references (not primitive types); object references as keys prevent GC collection

### Evidence Construction

After confirming a defect, the output must include:
- Collection declaration location and type (with file:line number)
- Write paths and frequency (from which call paths, how frequent)
- Missing eviction mechanism (no size limit, no TTL, no cleanup)
- Business impact (continuous memory growth, OOM after long runtime)

### Exclusions

- Cache implementations already with LRU/TTL/size limits
- Read-only collections loaded once at startup
- Short-lived collections (request-level, function-local variables)
- Collections with scheduled cleanup tasks (`setInterval` periodic `clear`)
