Benchmark 代码中存在 ThreadLocal 类加载器钉住 (ClassLoader Pinning) 的反模式

### 问题描述
在 `com.alibaba.fastjson2.benchmark.eishay.EishayParseBinaryArrayMapping` 中存在典型的 **ThreadLocal 类加载器钉住（ClassLoader Pinning）** 风险模式。
虽然该代码作为 JMH 基准测试运行在隔离的 Fork 进程中，用完即毁，不会引发实际内存泄漏。但考虑到 Fastjson 项目的影响力，很多开发者会将其 Benchmark 代码作为极致性能优化的“最佳实践”直接 Copy & Paste 到业务代码中。如果开发者将这种缺乏 `.remove()` 清理机制的 `ThreadLocal` 缓存模式直接搬到 Tomcat 或 Spring Boot 环境下，在应用发生热部署/热重载时，将引发致命的 `WebappClassLoader` 泄露，最终导致 `OutOfMemoryError: Metaspace`。

### 环境信息
- OS信息： [不受限 / All]
- JDK信息： [不受限 / All]
- 版本信息： [Fastjson2 最新版本]

### 重现步骤
该问题为静态代码结构隐患。问题代码定位：
1. 观察 `EishayParseBinaryArrayMapping` 类中的静态成员变量：
```java
private static final ThreadLocal kryos = ThreadLocal.withInitial(() -> {
Kryo kryo = new Kryo();
kryo.register(MediaContent.class);
// ... 其他注册
return kryo;
});

Start with com.alibaba.fastjson2.benchmark.eishay.EishayParseBinaryArrayMapping and inspect the static kryos declaration and its benchmark usage. Determine how cleanup should be handled without changing benchmark behavior; done means the classloader-pinning pattern is addressed and the benchmark remains functional.

Written by the indexing model from the issue text.