PermGen 空间中的 Java 类大小答案

【问题标题】：Java class size in PermGen spacePermGen 空间中的 Java 类大小
【发布时间】：2011-08-17 04:12:56
【问题描述】：

有很多关于 Java 对象大小的问答，这很容易理解。但我想知道 PermGen 空间中 Java 类的大小。

我对此感到疑惑的原因是因为我正在编写代码生成器，生成很多类。本质上，我为数据库中的每个表/视图生成两个类。现在我还想为外键关系建模。与其维护一个复杂的、可序列化的对象结构（考虑一个具有唯一键的表被属于其他具有其他外键的其他表的多个外键引用等），我更愿意为每个UNIQUE KEY 生成一个类和每个FOREIGN KEY 一节课。

这是我的问题：

我将在类加载器和 PermGen 空间上创建多少开销？
public 类、static 类和private 成员类之间有区别吗？
您发现在源代码中生成外键信息的更好方法了吗？

【问题讨论】：

听起来像是在 perm 空间填满时获取 OutOfMemoryErrors 的秘诀。
谢谢达菲莫。这就是我问的原因。不过，我对具体数字很好奇
没有，因为我不知道你正在生成什么。我很好奇 - 当您已经有这么多持久性解决方案（直接 JDBC、Hibernate、iBatis、TopLink、JPA 等）可用时，为什么您认为这是必要的？您的解决方案是什么？
Re: 3. 您是否看到在源代码中生成外键信息的更好方法？Hibernate 通过特定 FK/PK 列上的注释或 XML 配置数据来实现这一点。但我支持 duffymo，你所做的听起来与已经建立的 ORM 解决方案非常相似——除非你试图从原始数据库模式中自动提出域对象。
@duffymo：我正在开发jooq.org。我认为目前还没有类似的解决方案。您提到的所有解决方案都具有其他解决方案所没有的东西。详情请查看手册。

标签： java memory code-generation permgen

【解决方案1】：

我找到了一个不同的解决方案，它不像为每个KEY 生成一个类那样浪费内存。我生成了一个大致如下所示的类：

public class References {

    // First, initialise all unique keys
    public static final UniqueKey<TAuthorRecord> SysPk_14655 = 
        createUniqueKey(TAuthor.T_AUTHOR, TAuthor.ID);


    // Then initialise all foreign keys
    public static final Reference<TBookRecord, TAuthorRecord> SysFk_14666 = 
        createReference(SysPk_14655, TBook.T_BOOK, TBook.AUTHOR_ID);
    public static final Reference<TBookRecord, TAuthorRecord> SysFk_14667 = 
        createReference(SysPk_14655, TBook.T_BOOK, TBook.CO_AUTHOR_ID);


    // Factory method for unique keys
    protected static <R extends Record> UniqueKey<R> 
    createUniqueKey(Table<R> table, TableField<R, ?>... fields) {

    // Factory method for foreign keys referencing unique keys
    protected static <R extends Record, U extends Record> Reference<R, U> 
    createReference(UniqueKey<U> key, Table<R> table, TableField<R, ?>... fields) {

}

然后，生成的表类中的实际表可以引用和使用上述键。我在他的一个 cmets 中查看了 BobG 建议的 JPA 注释。但我觉得描述它们并不是很有用：

多字段键（@IdClass 需要一个类型作为参数，我想避免该类型）
多字段引用（怎么做？）
使用不同的键从一个表到另一个表的多个引用
唯一键，与主键共享许多属性。

一些 cmets 提到了为什么我应该创建这样一个生成器，因为有很多已建立的框架。我这样做是为了http://www.jooq.org。而且我觉得 jOOQ 正在填补当今数据库抽象可能性方面的空白。

【讨论】：

我承认，在我的日常工作（Spring/Hibernate 项目）中，我每周都会评估 Hibernate 是否真的节省了我的时间。（与使用 Hibernate 相比，我当然更喜欢使用 SQL。）我通常会得出结论，Hibernate 为我节省了大约 20% 的时间，否则我将花费在 DAO 层上。然而，对于复杂的查询——比如报告——我会恢复到直接的 SQL 并绕过大部分 Hibernate。
@BobG，那么你应该给 jOOQ 一个机会。它会在 DAO 层上为您节省大约相同数量甚至更多的时间，并且您也可以将它用于复杂的查询...