Key Motivation

The existingPatternFilter class is effective for single-threaded use but has two critical limitations in concurrent environments:

1. It is not thread-safe.
2. It is expensive to instantiate, as eachnew PatternFilter() triggers a full Hyperscan database compilation.

This forces consumers to implement their own complex and error-prone pooling orThreadLocal management to use Hyperscan filtering safely and efficiently in multi-threaded applications like web servers.

This PR introducesScopedPatternFilterFactory as a high-level, managed solution that solves these problems out of the box.

Key Differences & Improvements

The newScopedPatternFilterFactory supersedes the manualPatternFilter approach by providing:

• Thread-Safety by Design: The factory manages a unique, isolatedScopedPatternFilter instance for each thread, eliminating the need for external synchronization.

• High Performance via Caching: The expensive database compilation is performed only once per thread. Subsequent requests for a filter on the same thread reuse the already-compiled instance, drastically improving performance.

• Simplified and Safer API: Users interact with a single factory instance and obtain a filter viatry-with-resources (var filter = factory.get()). This returns a proxy that prevents accidental closure of the shared, thread-local resource.

• Automatic Resource Cleanup: It introduces a robust,PhantomReference-based mechanism to automatically release native resources for threads that have terminated, preventing memory leaks in dynamic environments.