Java：JITC的反映通胀是什么？
我最近遇到了这个有趣的术语，并在网上搜索了解更多信息。 然而，我发现的信息是粗略的。 有人可以吗。 给我一个详细的解释，这是什么，为什么这有用？
从我发现的信息来看，看起来这种机制使得reflection方法的执行速度更快，代价是创建了大量动态类并占用了perm gen内存区域，但我不确定。
是否有一些源代码挖掘和编码自己来解决这个问题，这就是我发现的：
Java的’Method’类有一个’MethodAccessor’类型的成员变量’methodAccessor’，它是一个方法’invoke’的接口，类似于Method的invoke。 方法调用委托给methodAccessor的调用。
如果启用了通胀（noInflation为false），则此访问器指向使用JNI运行此Java方法的实现（我认为使用api类似GetObjectClass，GetMethodID和Call * Method）。 这就像决斗调度一样，由于这个原因和其他原因，JNI的执行很慢。 （ 是什么让JNI呼叫变慢？ ）
通过reflection执行15次方法（’15’是默认值并且可以更改）并且noInflation为false后，基于JNI的访问器动态创建一个类（名称是动态生成的，例如说’GeneratedMethodAccessor1’），它也有调用方法。 现在，在这个’invoke’方法中，它将第一个’obj’参数强制转换为其对应的类，然后在其上调用目标方法。 然后，它创建此类的实例，并更改methodAccessor设置，以便此后每次执行该方法都委托给此实例而不是JNI访问器。 这被称为通货膨胀。
因为此实例是委托给Java对象的Java类，所以此后的委托是普通的Java委托。 它永远不会进入JNI，因此节省了开销，加上JITC可以对其进行其他优化，因为它变得高效。
缺点是，如果很多方法以这种方式膨胀，它们的类占用permgen空间并且可能导致内存不足错误。
有关详情，请参阅：
http://java.sun.com/docs/books/jni/html/fldmeth.html
http://anshuiitk.blogspot.com/2010/11/excessive-full-garbage-collection.html
Java Inflation是通过Java Reflection API进行的方法调用的优化。 它将不频繁的方法调用委托给廉价，立即可用但速度较慢的Java Native Interface，并对快速但昂贵的运行时生成的方法访问器进行 频繁的方法调用。
虽然不确定但是在某个地方读取它通知意味着对于reflection方法/构造函数的前几次运行（默认为15）（从现在开始，对方法的任何引用也适用于构造函数），它通过JNI实现; 在下一次之后，它会动态组装一个类文件并加载它。 此时，应用完整的JITting，对该reflection方法的进一步调用与直接调用该方法的性能相同