确定 PermGen 空间中单个 Java 类定义的大小？
如何确定单个特定类定义（而不是实例化对象）有多大？具体来说，给定的类使用了多少 PermGen 内存？如果无法计算，它与未压缩的 .class 文件的文件系统大小大致对应多少？
我读过 Jon Masamitsu，关于 PermGen 的内容：
- Java 类
- 方法 的基本字段类的名称（包括字节码）
- 类的名称（以对象的形式指向永久代中的字符串）
- 常量池信息（从类文件读取的数据，请参阅第 4 章） JVM 规范的所有细节）。
- 与类关联的对象数组和类型数组（例如，包含对方法的引用的对象数组）。
- JVM 创建的内部对象（例如 java/lang/Object 或 java/lang/exception）
- 编译器 (JIT) 用于优化的信息
最后两个可能与单个类定义无关。我对其余的感兴趣。
我发现的唯一可能的近似值是 java.lang.instrument.Instrument.getObjectSize(myObject.getClass()); 但是描述中的“部分或全部”让我小于对准确性充满信心。有什么想法吗？我觉得我忽略了一些简单的事情。
How do I determine how large a single, specific class definition (not the instantiated object) is? Specifically, how much PermGen memory does a given class use? If it cannot be calculated, how roughly does it correspond to the filesystem size of the uncompressed .class file?
I've read Jon Masamitsu, on what PermGen holds:
- Basic fields of a Java class
- Methods of a class (including the bytecodes)
- Names of the classes (in the form of an object that points to a string also in the permanent generation)
- Constant pool information (data read from the class file, see chapter 4 of the JVM specification for all the details).
- Object arrays and type arrays associated with a class (e.g., an object array containing references to methods).
- Internal objects created by the JVM (java/lang/Object or java/lang/exception for instance)
- Information used for optimization by the compilers (JITs)
The last two may possibly not be relevant to an individual class defintion. I'm interested in the rest.
The only possible approximation I've found isjava.lang.instrument.Instrument.getObjectSize(myObject.getClass()); but the "some or all" in the description leaves me less than confident in the accuracy. Any ideas? I feel like I'm overlooking something simple.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您唯一可以做的就是在加载类之前和之后查看 PermGen 大小，但是随着其方法被（重新）编译，它会继续使用更多内存。
The only thing you can do is look at the PermGen size is before and after loading a class, however it continues to use more memory as its methods get (re)compiled.