g*g
2 楼
不要google,这里的大牛们有几个知道的举手吧。
发现是从1.2就有的类,这么多年我完全没接触过。
发现是从1.2就有的类,这么多年我完全没接触过。
c*t
4 楼
你这一说我才发现。有这东西。看来俺以前理解错了。
From wikipedia:
A soft reference is one of the strengths or levels of 'non strong' reference
defined in the Java programming language, the others being weak and phantom.
The garbage collector will always collect weakly referenced objects, but
will only collect softly referenced objects when its algorithms decide that
memory is low enough to warrant it. Soft and weak references provide two
quasi-priorities for non-strongly referenced objects.
Soft references may be used,
【在 g*****g 的大作中提到】
: 不要google,这里的大牛们有几个知道的举手吧。
: 发现是从1.2就有的类,这么多年我完全没接触过。
From wikipedia:
A soft reference is one of the strengths or levels of 'non strong' reference
defined in the Java programming language, the others being weak and phantom.
The garbage collector will always collect weakly referenced objects, but
will only collect softly referenced objects when its algorithms decide that
memory is low enough to warrant it. Soft and weak references provide two
quasi-priorities for non-strongly referenced objects.
Soft references may be used,
【在 g*****g 的大作中提到】
: 不要google,这里的大牛们有几个知道的举手吧。
: 发现是从1.2就有的类,这么多年我完全没接触过。
m*t
5 楼
That's subtly different than what Sun's javadoc says
though - the "will only" part especially.
reference
phantom.
that
【在 c*****t 的大作中提到】
: 你这一说我才发现。有这东西。看来俺以前理解错了。
: From wikipedia:
: A soft reference is one of the strengths or levels of 'non strong' reference
: defined in the Java programming language, the others being weak and phantom.
: The garbage collector will always collect weakly referenced objects, but
: will only collect softly referenced objects when its algorithms decide that
: memory is low enough to warrant it. Soft and weak references provide two
: quasi-priorities for non-strongly referenced objects.
: Soft references may be used,
though - the "will only" part especially.
reference
phantom.
that
【在 c*****t 的大作中提到】
: 你这一说我才发现。有这东西。看来俺以前理解错了。
: From wikipedia:
: A soft reference is one of the strengths or levels of 'non strong' reference
: defined in the Java programming language, the others being weak and phantom.
: The garbage collector will always collect weakly referenced objects, but
: will only collect softly referenced objects when its algorithms decide that
: memory is low enough to warrant it. Soft and weak references provide two
: quasi-priorities for non-strongly referenced objects.
: Soft references may be used,
g*g
6 楼
My question is really whether you guys used it or knew it
before. I for one, had no idea about it at all, and felt
embarrassed when asked about this in an interview.
【在 m******t 的大作中提到】
: That's subtly different than what Sun's javadoc says
: though - the "will only" part especially.
:
: reference
: phantom.
: that
before. I for one, had no idea about it at all, and felt
embarrassed when asked about this in an interview.
【在 m******t 的大作中提到】
: That's subtly different than what Sun's javadoc says
: though - the "will only" part especially.
:
: reference
: phantom.
: that
m*t
7 楼
I wrote some cache using a soft reference
map before (to cache reflection results).
Oh they love these useless questions, don't they?
【在 g*****g 的大作中提到】
: My question is really whether you guys used it or knew it
: before. I for one, had no idea about it at all, and felt
: embarrassed when asked about this in an interview.
g*g
8 楼
Well, I know most questions can be answered by googling in 5 minutes.
But it can be the difference maker in their decision. At least it's
part of JDK, can't blame them on that.
Once I was tricked to answer how good you are with hibernate, I said 8 or 9,
by that I mean with google. Then I was served with some tricky hibernate
questions.
【在 m******t 的大作中提到】
:
: I wrote some cache using a soft reference
: map before (to cache reflection results).
: Oh they love these useless questions, don't they?
But it can be the difference maker in their decision. At least it's
part of JDK, can't blame them on that.
Once I was tricked to answer how good you are with hibernate, I said 8 or 9,
by that I mean with google. Then I was served with some tricky hibernate
questions.
【在 m******t 的大作中提到】
:
: I wrote some cache using a soft reference
: map before (to cache reflection results).
: Oh they love these useless questions, don't they?
d*d
13 楼
the differences are:
1. when to become a GC candidate..
2. when ref queue gets notified...
1. when to become a GC candidate..
2. when ref queue gets notified...
F*n
14 楼
This is similar to C++'s memory allocation problem (which is the entire
purpose of GC). Imagine you have a GUI (say a tree) that listens to a GUI
Model (say a TreeModel). Usually in your tree you create a listener and add
it to TreeModel to update UI. Then when your tree is disposed (and your
TreeModel is not) you have to explicitly remove the listener, otherwise the
hard reference will be inside TreeModel forever and cause memory leak. On
the other hand, if the listener is stored as WeakReferen
【在 m******t 的大作中提到】
:
: So whether/when a listener stops getting events is at the mercy of the
: garbage
: collector?
purpose of GC). Imagine you have a GUI (say a tree) that listens to a GUI
Model (say a TreeModel). Usually in your tree you create a listener and add
it to TreeModel to update UI. Then when your tree is disposed (and your
TreeModel is not) you have to explicitly remove the listener, otherwise the
hard reference will be inside TreeModel forever and cause memory leak. On
the other hand, if the listener is stored as WeakReferen
【在 m******t 的大作中提到】
:
: So whether/when a listener stops getting events is at the mercy of the
: garbage
: collector?
m*t
15 楼
add
the
Hmm... interesting technique.
This does imply a slight performance penalty though, doesn't it?
Every time before the TreeModel tries to call the listener, it needs
to make sure that the reference is not null.
【在 F****n 的大作中提到】
: This is similar to C++'s memory allocation problem (which is the entire
: purpose of GC). Imagine you have a GUI (say a tree) that listens to a GUI
: Model (say a TreeModel). Usually in your tree you create a listener and add
: it to TreeModel to update UI. Then when your tree is disposed (and your
: TreeModel is not) you have to explicitly remove the listener, otherwise the
: hard reference will be inside TreeModel forever and cause memory leak. On
: the other hand, if the listener is stored as WeakReferen
F*n
16 楼
Hehe, everything has a penalty. Actually checking for null pointers is one
of the main reasons Java is slower than C...
If you really want to optimize, you can put it in a try / catch block and
catch the NullPointerException.
【在 m******t 的大作中提到】
:
: add
: the
: Hmm... interesting technique.
: This does imply a slight performance penalty though, doesn't it?
: Every time before the TreeModel tries to call the listener, it needs
: to make sure that the reference is not null.
of the main reasons Java is slower than C...
If you really want to optimize, you can put it in a try / catch block and
catch the NullPointerException.
【在 m******t 的大作中提到】
:
: add
: the
: Hmm... interesting technique.
: This does imply a slight performance penalty though, doesn't it?
: Every time before the TreeModel tries to call the listener, it needs
: to make sure that the reference is not null.
s*n
17 楼
be careful though. typically the listener is created thru annonymous
inner class. it has a reference to the tree, the tree doesn't have
a reference to the listener. this creates two problems, the listener
could be GC'ed prematurely, and the tree could miss normal GCs.
using soft refrence in cache is usually a mistake too. a cache should
have its own policy deciding which objects should be kept and which
should be kicked out. keep everything, untill a full GC, then kick out
everything, that would
【在 F****n 的大作中提到】
: This is similar to C++'s memory allocation problem (which is the entire
: purpose of GC). Imagine you have a GUI (say a tree) that listens to a GUI
: Model (say a TreeModel). Usually in your tree you create a listener and add
: it to TreeModel to update UI. Then when your tree is disposed (and your
: TreeModel is not) you have to explicitly remove the listener, otherwise the
: hard reference will be inside TreeModel forever and cause memory leak. On
: the other hand, if the listener is stored as WeakReferen
inner class. it has a reference to the tree, the tree doesn't have
a reference to the listener. this creates two problems, the listener
could be GC'ed prematurely, and the tree could miss normal GCs.
using soft refrence in cache is usually a mistake too. a cache should
have its own policy deciding which objects should be kept and which
should be kicked out. keep everything, untill a full GC, then kick out
everything, that would
【在 F****n 的大作中提到】
: This is similar to C++'s memory allocation problem (which is the entire
: purpose of GC). Imagine you have a GUI (say a tree) that listens to a GUI
: Model (say a TreeModel). Usually in your tree you create a listener and add
: it to TreeModel to update UI. Then when your tree is disposed (and your
: TreeModel is not) you have to explicitly remove the listener, otherwise the
: hard reference will be inside TreeModel forever and cause memory leak. On
: the other hand, if the listener is stored as WeakReferen
F*n
18 楼
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The first problem is indeed a trap. Normally in my application I use
TreeModel.addListener(Listener listener, int RefType)
to explicitly declare the listener's reference type, and set
TreeModel.addListener(Listener listener) to use hard reference.
You second problem is not a problem because if the listener becomes weakly
reachable (nobody reference it), then its reference to the tree will become
weakly reachable too if the tree does not have oth
【在 s******n 的大作中提到】
: be careful though. typically the listener is created thru annonymous
: inner class. it has a reference to the tree, the tree doesn't have
: a reference to the listener. this creates two problems, the listener
: could be GC'ed prematurely, and the tree could miss normal GCs.
: using soft refrence in cache is usually a mistake too. a cache should
: have its own policy deciding which objects should be kept and which
: should be kicked out. keep everything, untill a full GC, then kick out
: everything, that would
s*n
19 楼
I don't understand your argument. once again, if the listener has only
one weak reference to it, GC could discard the listener anytime. it can
de-reference it prematurely before the tree is disposed, or, it may choose
to never dereference it, even long after the tree is disposed (and the tree
itself, and everything the tree references, will not be GC'ed as well)
there is no 'advantage' of GC. it is a necessary evil because we don't
have unlimited memories. it is unpredictable and undeterministic
【在 F****n 的大作中提到】
:
: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: The first problem is indeed a trap. Normally in my application I use
: TreeModel.addListener(Listener listener, int RefType)
: to explicitly declare the listener's reference type, and set
: TreeModel.addListener(Listener listener) to use hard reference.
: You second problem is not a problem because if the listener becomes weakly
: reachable (nobody reference it), then its reference to the tree will become
: weakly reachable too if the tree does not have oth
one weak reference to it, GC could discard the listener anytime. it can
de-reference it prematurely before the tree is disposed, or, it may choose
to never dereference it, even long after the tree is disposed (and the tree
itself, and everything the tree references, will not be GC'ed as well)
there is no 'advantage' of GC. it is a necessary evil because we don't
have unlimited memories. it is unpredictable and undeterministic
【在 F****n 的大作中提到】
:
: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: The first problem is indeed a trap. Normally in my application I use
: TreeModel.addListener(Listener listener, int RefType)
: to explicitly declare the listener's reference type, and set
: TreeModel.addListener(Listener listener) to use hard reference.
: You second problem is not a problem because if the listener becomes weakly
: reachable (nobody reference it), then its reference to the tree will become
: weakly reachable too if the tree does not have oth
F*n
20 楼
1. In my implementation, I use addListener(l, reftype), so if you want a
weak reference you should use this method explicitly, and know how it works.
That is to say you will keep a listener reference somewhere inside your
tree and so it will not be GCed until the tree itself is un-referenced.
Again, this is only for argument's sake. If you have developed disposable UI
, you should know anonymous class listener is NEVER a problem: if you want a
UI to be disposed, you MUST NOT use unreferenced ano
【在 F****n 的大作中提到】
:
: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: The first problem is indeed a trap. Normally in my application I use
: TreeModel.addListener(Listener listener, int RefType)
: to explicitly declare the listener's reference type, and set
: TreeModel.addListener(Listener listener) to use hard reference.
: You second problem is not a problem because if the listener becomes weakly
: reachable (nobody reference it), then its reference to the tree will become
: weakly reachable too if the tree does not have oth
weak reference you should use this method explicitly, and know how it works.
That is to say you will keep a listener reference somewhere inside your
tree and so it will not be GCed until the tree itself is un-referenced.
Again, this is only for argument's sake. If you have developed disposable UI
, you should know anonymous class listener is NEVER a problem: if you want a
UI to be disposed, you MUST NOT use unreferenced ano
【在 F****n 的大作中提到】
:
: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: The first problem is indeed a trap. Normally in my application I use
: TreeModel.addListener(Listener listener, int RefType)
: to explicitly declare the listener's reference type, and set
: TreeModel.addListener(Listener listener) to use hard reference.
: You second problem is not a problem because if the listener becomes weakly
: reachable (nobody reference it), then its reference to the tree will become
: weakly reachable too if the tree does not have oth
m*t
21 楼
That semantical requirement is too strong. As long as the model
validates the weak reference (as any code using weak references should)
before dereferencing it, it's fine.
【在 s******n 的大作中提到】
: I don't understand your argument. once again, if the listener has only
: one weak reference to it, GC could discard the listener anytime. it can
: de-reference it prematurely before the tree is disposed, or, it may choose
: to never dereference it, even long after the tree is disposed (and the tree
: itself, and everything the tree references, will not be GC'ed as well)
: there is no 'advantage' of GC. it is a necessary evil because we don't
: have unlimited memories. it is unpredictable and undeterministic
s*n
22 楼
the reference is still there, the event is dispatched to the listerner,
who tries to do something on the tree, while the tree has already been
disposed.
【在 m******t 的大作中提到】
:
: That semantical requirement is too strong. As long as the model
: validates the weak reference (as any code using weak references should)
: before dereferencing it, it's fine.
who tries to do something on the tree, while the tree has already been
disposed.
【在 m******t 的大作中提到】
:
: That semantical requirement is too strong. As long as the model
: validates the weak reference (as any code using weak references should)
: before dereferencing it, it's fine.
F*n
24 楼
Again, what you mean by "dispose"? There is no "dispose" for non-top containers. If you mean the tree is removed from the container, then the listener will generally do no harm. If you mean the tree is GCed, then the listener must have been GCed already.
There is no such case as the listener tries to do something to a GCed tree, because if the listener has a reference to the tree then the tree won't be GCed.
【在 s******n 的大作中提到】
: the reference is still there, the event is dispatched to the listerner,
: who tries to do something on the tree, while the tree has already been
: disposed.
There is no such case as the listener tries to do something to a GCed tree, because if the listener has a reference to the tree then the tree won't be GCed.
【在 s******n 的大作中提到】
: the reference is still there, the event is dispatched to the listerner,
: who tries to do something on the tree, while the tree has already been
: disposed.
相关阅读
请教关于java认证方面的问题Classpath questionsHow to add checkboxes to a textbox in MSWord?请推荐两本学习java的书Simple question: delete element from collection on condition?网页的Form中Post的问题 (转载)EJBGen想找几个模板JTabbedPane的一个问题 急问:ubuntu下安装j2ee sdk的奇怪错误Eclipse 3.1.1.1在ubuntu710下古怪现象想给程序加个最简单的窗口界面,请帮忙Eclipse一问爪哇的铜锈们新年好!Struts基本思路请教Java虚拟磁盘问题JMX questionhow to hide and show the cursor in JTextField?marshall 和 serialize 的区别?在一个文本文件后面添加行怎么做?