当前位置: 首页 > 知识库问答 >
问题:

垃圾收集在java中似乎不起作用

晏德佑
2023-03-14

下面的方法有2个for循环。Firstloop迭代36000次,inner forloop迭代24次,因此记录插入的总数将为864000。代码执行运行了将近3.5小时并终止。(记录插入失败)只有在outer for循环结束后才会关闭会话并提交事务。发现执行过程中RAM消耗近6.9GB

@SuppressWarnings("unchecked")


public void createBRResults() {

    List<BusinessRules> businessRuleList = null;
    Organization organization = null;
    Brresults brresults = null;
    Criteria criteria = null;
    Criteria newCriteria = null;
    String brStatus = "Live";
    Date date = new Date();
    Session session = sessionFactory.openSession();
    Transaction transaction = null;
    try {
        if (callInfos == null) {
            callInfos = getEntities(CallInfo.class);
        }
        for (CallInfo callInfo : callInfos) {
            transaction = session.beginTransaction();
            criteria = session.createCriteria(BusinessRules.class);
            criteria.createCriteria("businessGoals").add(
                    Restrictions.eq("category", callInfo.getCategory()));
            businessRuleList = criteria.list();
            organization = callInfo.getOrganization();
            for (BusinessRules businessRule : businessRuleList) {
                brresults = new Brresults();
                brresults.setBusinessRule(businessRule);
                brresults.setCallInfo(callInfo);
                brresults.setCreatedDate(date);
                brresults.setModifiedDate(date);
                brresults.setOrganization(organization);
                brresults.setBrrStatus(brStatus);
                brresults.setBrrValue(Math.random() < 0.5 ? 0 : 1);
                session.save(brresults);
                brresults = null;
            }
            criteria = null;
            organization = null;
            businessRuleList = null;
            session.flush();
            session.clear();
            transaction.commit();
            System.gc();
        }
    } catch (Exception ex) {
        ex.printStackTrace();
    } finally {
        session.close();
    }
}

我已经附上了最后几行GC日志来指示内存分配

堆PSYoungGen总计1862144K,已使用889367K[0x0000000715D80000,0x00000007BDC80000,0x00000007C0000000)

eden空间979968K,90%使用[0x0000000715D80000,0x000000074C205E48,0x0000000751A80000)从空间882176K,0%使用[0x0000000787F00000,0x0000000787F00000,0x00000007BDC80000)到空间885760K,0%使用[0x0000000751A80000,0x0000000751A80000,0x0000000787B80000)ParOldGen总计5576192K,使用5576027K[0x00000005C1800000,0x00000007B80000

但如果我关闭会话并每隔24次重复再次打开会话,则记录插入成功,所需时间为55分钟。但RAM利用率约为3GB。

为什么垃圾收集不能正常进行?代码中有哪些bug?

共有1个答案

步衡
2023-03-14

session正在累积对您所接触的所有对象的引用,因为如果您在同一会话中两次请求该对象,它必须返回完全相同的对象。您需要定期关闭它以允许它丢弃其上下文。

 类似资料:
  • 本文向大家介绍Java垃圾收集,包括了Java垃圾收集的使用技巧和注意事项,需要的朋友参考一下 示例 C ++方法-新增和删除 在像C ++这样的语言中,应用程序负责管理动态分配的内存所使用的内存。当使用new运算符在C ++堆中创建对象时,需要相应地使用delete运算符来处置该对象: 如果程序忘记了delete一个对象而只是“忘记”了该对象,则关联的内存将丢失给应用程序。这种情况的术语是内存泄

  • Kubernetes 垃圾收集器的角色是删除指定的对象,这些对象曾经有但以后不再拥有 Owner 了。 注意:垃圾收集是 beta 特性,在 Kubernetes 1.4 及以上版本默认启用。 Owner 和 Dependent 一些 Kubernetes 对象是其它一些的 Owner。例如,一个 ReplicaSet 是一组 Pod 的 Owner。具有 Owner 的对象被称为是 Owner

  • 有人能给我解释一下原因吗?

  • 问题内容: 简短形式:CMS垃圾收集器似乎无法收集数量不断增加的垃圾;最终,我们的JVM填满,应用程序变得无响应。通过外部工具(JConsole或)强制GC 清理一次。 更新:该问题似乎与JConsole的JTop插件有关。如果我们不运行JConsole,或者在没有JTop插件的情况下运行它,则该行为消失。 (技术说明:我们正在Linux 2.6.9机器上运行32位Sun JDK 1.6.0_07

  • JavaScript 具有自动垃圾收集机制,也就是说,执行环境会负责管理代码执行过程中使用的内存。 而在C 和C++之类的语言中,开发人员的一项基本任务就是手工跟踪内存的使用情况,这是造成许多问题的一个根源。在编写JavaScript 程序时,开发人员不用再关心内存使用问题,所需内存的分配以及无用内存的回收完全实现了自动管理。这种垃圾收集机制的原理其实很简单:找出那些不再继续使用的变量,然后释放其

  • 问题内容: 有人可以解释一下G1垃圾收集器的工作原理吗?我还无法在任何地方找到任何全面,易于理解的描述。 谢谢 问题答案: 收集器将堆分成固定大小的区域,并跟踪这些区域中的实时数据。它将一组指针(“记住的集”)保留在区域内和区域外。当认为有必要使用GC时,它将首先收集实时数据较少的区域(因此,“垃圾优先”)。通常,这意味着一步就可以收集整个区域:如果进入一个区域的指针数量为零,则无需对该区域进行标