我最近遇到了这个有趣的术语，并在网上搜索了解更多信息。然而，我发现的信息是粗略的。有人可以吗。给我一个详细解释这是什么，为什么这有用？
从我发现的信息来看，看起来这种机制使得反射方法的执行速度更快，代价是创建了大量动态类并占用了perm gen内存区域，但我不确定。
答案 0 :(得分：16)
是否有一些源代码在编写和编写代码来解决这个问题，这就是我发现的：
Java的'Method'类有一个'MethodAccessor'类型的成员变量'methodAccessor'，它是一个方法'invoke'的接口，类似于Method的invoke。方法调用委托给methodAccessor的调用。
如果启用了通胀（noInflation为false），则此访问器指向使用JNI运行此Java方法的实现（我认为使用api类似GetObjectClass，GetMethodID和Call * Method）。这就像决斗调度一样，由于这个原因和其他原因，JNI的执行很慢。 （What makes JNI calls slow?）
通过反射执行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
答案 1 :(得分：2)
Java Inflation是通过Java Reflection API进行的方法调用的优化。它将infrequent方法调用委托给廉价，即时可用但速度较慢的Java Native Interface和frequent方法调用快速但昂贵的运行时generated method accessor。
答案 2 :(得分：1)
虽然不确定，但在某处读到了这个 通货膨胀意味着对于反射方法/构造函数的前几次运行（默认为15）（从现在开始，对方法的任何引用也适用于构造函数），它通过JNI进行;在下一次之后，它会动态组装一个类文件并加载它。此时，应用完整的JITting，并且对该反射方法的进一步调用与直接调用该方法具有相同的性能