我们有一个批处理作业，从数据库中读取数据并将其写入文件。这个作业写在springbatch2.8之上。我们已经注意到，它占用了大量的内存，正在尝试调整它。我在做练习时有一些问题
我知道不建议实现finalize（）。在我读过的许多文章中，他们说对象可能被推送到referencequeue，终结器线程轮询队列。有没有办法，我可以自己检查队列(我知道内存转储会显示这一点，但有时文件太大，无法从实时系统传输到本地计算机并执行诊断）。
普通和非普通finalize（）方法之间到底有什么区别？找不到解释这个的文章。
如果finalize（）方法不是一个好主意，为什么abstractplainsocketimpl、fileinputstream和其他人要实现它？他们的finalize方法如何帮助他们在gc中不成为不可访问或死代码的一部分？
使用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.