Java最终方法,SocksSocketImpl,Profile等



我们有一个批处理作业,它从数据库中读取数据并将其写入文件。该作业写在 Spring Batch 2.8 之上。我们已经注意到,它占用了大量内存,并正在尝试对其进行调整。我在进行练习时有一些问题

  1. 我知道不建议实现 finalize()。在我读过的许多帖子中 - 他们说对象可能会被推送到 ReferenceQueue,并且 Finalizer 线程会轮询队列。那么有没有办法,我可以自己检查队列?(我知道内存转储会显示这一点,但有时文件太大,无法从实时系统传输到本地计算机并执行诊断)。

  2. 平凡和非平凡的 finalize() 方法到底有什么区别?找不到解释这一点的文章。

  3. 如果 finalize() 方法不是一个好主意,为什么 AbstractPlainSocketImpl、FileInputStream 和其他方法要实现它?这是怎么回事,他们的最终方法可以帮助他们在 GC 中而不是成为无法访问或死代码的一部分?

  4. 使用 jvisualvm 或 jmc 时 - 提交的堆大小显示为 600MB。但是当我在我们的 Linux 环境中执行以下命令时,它显示内存为 800MB+。

    ps --cols 500 -C java -o user,ppid,pid,pcpu,rss,size,vsize,cmd | grep <uid> | awk '{ print $3,$4,$5/1024}'
    

环境详细信息

    Number of cores: 2
    OS: Red Hat Enterprise Linux Server release 6.5
    Total Physical Memory: 7.69GB
    JVM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08) for linux-amd64 JRE (1.7.0_45-b18)
    JVM Command Line Arguments: -Xloggc:../logs/Job-gc.log -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -XX:-PrintTenuringDistribution -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=5M -XX:-CITime -XX:-PrintClassHistogram -XX:-PrintConcurrentLocks -XX:-PrintAdaptiveSizePolicy -XX:-TraceClassLoading -XX:-TraceClassUnloading -XX:+UnlockCommercialFeatures -XX:+FlightRecorder -Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.port=7091 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname=server.com
    Garbage Collector used (this info is from JMC): ParallelScavenge for Young and ParallelOld for Old.

我知道内存转储会显示这一点,但有时文件太大,无法从实时系统传输到本地计算机并执行诊断

命令tar -czf dump.tar.gz dump.hprof可以帮助您传输该大文件。

3GB -> 100MB。

转储文件的压缩率会很高。

最新更新