Hibernate可以使您的模型了解Hibernate。
使用Reflection的成本水平不尽相同。不断地为特定类查找方法特别昂贵。通过使用缓存副本进行反射执行方法不会慢很多。如果考虑到反射api必须完成的任务才能调用该方法，那么每个部分都很慢并且会占用cpu周期就很有意义。
定位方法访问特定类的每种方法测试每种方法的可见性，方法签名等为 找到的 方法生成字节码。一个典型类中的方法数量受一个因素的影响，而其中一些操作琐碎琐碎，这显然很昂贵。
调用方法。每个反射的方法都包含一些字节代码，这些字节代码用一些样板代码调用目标方法以匹配反射接口。在它可以执行此操作之前，它必须执行一些健全性检查，以便它可以用漂亮的消息进行抱怨，而不是让运行时抛出ClassCastException和类似异常。
如果使用实例方法，请检查传入的实例是否为null且类型正确。检查arguments参数是否包含正确数量和类型的参数。在try catch中执行该方法。在投掷ITE等所有这些额外功能会增加一些成本-并不多，但确实会使事情变慢。
运行时间成本在一般的缓存方法中，调用该方法虽然不花钱，但速度较慢。反射api本身确实尝试缓存方法和类，但是找到正确的方法等等仍然是缓慢的操作。
解决方法很久以前，我正在使用反射创建一个迷你ORM。
在阅读有关反射的文章时，我得到了类似的答案：
这完全有道理，我退出了我的小命令并增强了CTRL + C，CTRL + V键（lib的目的是避免为我正在使用的Web应用程序中的不同表重复重写相同的代码段）
几年后，由于某种原因，我现在不记得（也不想记住）我正在阅读（或试图…）Hibernate源代码，因为我想知道他们是否使用AOP即时生成代码并避免反射惩罚，但令我惊讶的是，我所看到的全部都是纯反射。
难道这意味着那里是最被接受的ORM框架，到底是在什么年前阻止我继续我的幼稚工作的？：“）
我的问题是：有人可以证实我对Hibernate实现的理解吗？他们会即时生成字节码以提高性能吗？还是我们（当我们使用它时）总是付出反射惩罚（顺便说一句，如果差异在几毫秒之内，我们当中没有人注意到或抱怨过）
我们要付反思费吗？如果是的话，我认为这是 值得的！！！
问候。
