用于辅助反射的高性能对象缓存答案

【问题标题】：High Performance Object Cache for Aiding Reflection用于辅助反射的高性能对象缓存
【发布时间】：2013-09-02 17:50:53
【问题描述】：

我想知道是否有人可以提供任何建议。我已经为几个 POJO 编写了一个 Json 反序列化器/序列化器。为了使它们尽可能通用，它们依靠反射来反对 POJO getter/setter 方法等。由于这是对性能的最大影响，我尝试创建一种“ClassUtils”缓存，在检索后存储 Method 对象（我使用 Introspector 获取属性描述符列表，然后获取 get/set方法）

但是，我尝试首先使用 Guava LoadingCache - 虽然它有一些非常好的和有用的功能，但与我创建的自定义缓存相比，它非常慢 - 使用 Guava 缓存序列化 1,000 个对象需要 3.5 秒，并且只有

对于提高 Guava 性能或改进自定义缓存有什么建议吗？我不能像工作一样发布任何代码，但是我自己的自定义缓存基本上是存储 PropertyDescriptors 的 HashMap 的包装器，使用字符串作为键（我需要将键存储为完整的类名加上属性名称，例如“com.company.package.classes.myclass.property”）

【问题讨论】：

使用 Jackson，可以选择使用 afterburner 来将反射替换为字节码生成。不幸的是，没有代码就无法调试 Guava。 ConcurrentLinkedHashMap 仍然比 Guava 端口快，但许多功能只是添加到 Guava 中。

标签： java caching

【解决方案1】：

我不会使用 JSON。如果使用二进制格式，则序列化/反序列化的性能可能会提高 10 - 100 倍，具体取决于数据结构的复杂程度。如果你想要性能，你会避免让一切都变得完全通用。

只需几行代码，您就可以将 LinkedHashMap 用作 LRU 缓存。

将每个属性存储为单独的键比使用适当的对象慢大约一个数量级。（同样，这不太通用，但效率更高）

【讨论】：

我必须使用 Json :( 我一直在尝试将属性存储为对象，即将 get/set/constructor 方法存储在一个对象中，以属性名称作为似乎有的键提高了速度
另外，由于存储方法的每个对象都是不可变的，缓存哈希码也提高了性能
与其猜测问题可能是什么，不如在分析器中运行代码时，您认为性能瓶颈是什么？我建议你同时打开内存和 CPU 分析。