java - hibernate 实现。我们要支付反射惩罚吗？

Question

很久以前，我正在使用反射创建一个迷你 ORM。

在阅读有关反射的文章时，我得到了类似这样的答案:

Java Reflection Performance

这完全有道理，我退出了我的迷你 orm 并加强了我的 CTRL+C、CTRL+V 键(该库旨在避免在我正在工作的 Web 应用程序中为不同的表一次又一次地重写相同的片段上)

多年后出于某种原因我现在不记得(也不想记住)我正在阅读(或试图...)Hibernate 源代码，因为我想知道他们是否使用 AOP 生成代码飞行并避免反射惩罚，但令我惊讶的是，我看到的所有东西都是纯粹的反射。

这是否意味着最被接受的 ORM 框架在几年前确实阻止了我继续我天真的努力？ :")

我的问题是:有人可以确认我对 Hibernate 实现的理解吗？他们是否动态生成字节码以提高性能？或者我们(当我们使用它时)是否总是支付反射惩罚(顺便说一句，如果差异在几毫秒内，我们都没有注意到或提示过)

我们是否正在支付反射惩罚？如果我们是，我认为这是值得的!!!

问候。

Answer 1

Hibernate 检测您的模型以感知 hibernate 。

使用反射的成本各不相同。不断查找特定类的方法特别昂贵。使用缓存副本通过反射执行方法并没有那么慢。如果一个人想到反射 api 必须完成的任务来调用方法，那么每个部分都很慢并且消耗 cpu 周期都是有道理的。

定位方法

• 访问特定类的每个方法
• 测试每个方法的可见性、方法签名等。
• 为found 方法生成字节码。

典型类中的方法数量以及其中一些操作并非微不足道的一个因素很明显，这可能代价高昂。

调用方法。

每个反射方法相当于一些字节代码，它调用带有一些样板的目标方法来匹配反射接口(interface)。在执行此操作之前，它必须执行一些健全性检查，以便它可以用友好的消息进行提示，而不是让运行时抛出 ClassCastException 和类似的异常。

• 如果实例方法检查传入的实例不为空且类型正确。
• 检查 arguments 参数包括正确的参数数量和类型。
• 在 try catch 中执行该方法。在 catch throw ITE 等。

所有这些额外的东西都会增加一些成本 - 不是很多，但确实会让事情变得更慢。

运行时成本

一般来说，缓存方法和调用是没有成本的，但速度有点慢。反射 api 本身确实尝试缓存方法和类，但找到正确的方法等仍然是一个缓慢的操作。