d****g
发帖数: 7460 | 1 有一个方法如下。
void test(){
Object o = session.get("ABC");
session.remove("ABC");
Object b = transform(o);
b.write(buf);
}
因为o非常大。所以关心GC的问题。o实际上过了transform就不用了，可以被回收了。
但JVM够聪明吗？这是个实际问题，现在b.write(buf)仍OOM。想知道在write之前设o为
null会不会有用。 |
w**z
发帖数: 8232 | 2 the o is the reference get back from session.get(). How does the session
hold the reference? You need to clear it out from session in order for JVM
to GC it. |
d****g
发帖数: 7460 | 3 Session.remove is called. It is actually just httpsession.
o是唯一reference了。但o在什么时候eligible呢。是方法执行完，还是right away?
JVM
【在 w**z 的大作中提到】
: the o is the reference get back from session.get(). How does the session
: hold the reference? You need to clear it out from session in order for JVM
: to GC it.
|
w**z
发帖数: 8232 | 4 It's JVM's implementation when GC happens. No guarantee when it will happen.
http://stackoverflow.com/questions/9527491/can-i-force-garbage-
【在 d****g 的大作中提到】
: Session.remove is called. It is actually just httpsession.
: o是唯一reference了。但o在什么时候eligible呢。是方法执行完，还是right away?
:
: JVM
|
g*****g
发帖数: 34805 | 5 In my experience, anything trying to tamper GC will backfire. You may hint
JVM to GC, you may even wait for JVM to GC. But OOM is such a big deal, even
if you are successful 999 out of 10000 time, the other time leaves you with
a crashed server and you can't afford that. You may hide the problem in dev
and test and only get it crash in prod under load. Something you really
really want to avoid.
I think you should take a profiler, and check what's leaking memory instead.
It may be just a bug somewhere. e.g. Did you close your write?
【在 d****g 的大作中提到】
: Session.remove is called. It is actually just httpsession.
: o是唯一reference了。但o在什么时候eligible呢。是方法执行完，还是right away?
:
: JVM
|
