集算器疑似内存泄漏 - finalize()

集算器版本:20230520
调用方式:远程计算即

761b6ef678e84b3f9ff7bff396f8a6c1_png

通过 MAT 进行内存分析如下

png
finalize 方法被调用

png

finalize 方法 我理解的为了兜底 可是底层只有一个线程去负责这个操作 当并发查询的时候 肯定是赶不上 生成的速度的 很容易堆溢出
通过 jvisualVm 进行观察 拿到数据后大约要 2 分钟左右才进行了释放。

关于 finalize 方法的案例可以参考百度
https://www.cnblogs.com/wftop1/p/15021386.html

发现 jdk9 开始此方法已经弃用。

png

建议还是从程序上去显式的去释放资源 不要去期望这个 finalize 方法。

对应的执行的脚本语句:

==now()
=days@o(date(“1995-03-15”)) =date(“03/15/1995”)
/>mktsegment=c_mktsegment.pos@b(“BUILDING”)
=file(“/data/soft/esProc/file/Performance_Spl/CUSTOMER.ctx”).open().cursor@m (C_CUSTKEY;).fetch().keys@im(C_CUSTKEY)
=file(“/data/soft/esProc/file/Performance_Spl/ORDERS.ctx”).open().cursor@m (O_ORDERKEY,O_ORDERDATE,O_SHIPPRIORITY;O_ORDERDATE>date($B_ORDERDATE) && O_ORDERDATE
=file(“/data/soft/esProc/file/Performance_Spl/LINEITEM.ctx”).open().news@r (A5,O_ORDERKEY,sum(L_EXTENDEDPRICE*(1-L_DISCOUNT)):REVENUE,O_ORDERDATE,O_SHIPPRIORITY;L_SHIPDATE>B2)
=A6.fetch()
参数:
B_ORDERDATE:1995-03-25 00:00:00 E_ORDERDATE:1995-03-31 00:00:00
这个 spl 语句 估计不是最优的 我只是通过这个例子来说明 使用 finalize 的弊端而已 望理解。不用纠结这个执行语句的写法