g*****g
发帖数: 34805 | 1 不要google，这里的大牛们有几个知道的举手吧。
发现是从1.2就有的类，这么多年我完全没接触过。 |
c*****t
发帖数: 1879 | 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
发帖数: 2416 | 3 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,
|
g*****g
发帖数: 34805 | 4 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
|
m******t
发帖数: 2416 | 5
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
发帖数: 34805 | 6 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?
|
F****n
发帖数: 3271 | 7 I use it all the time
【在 g*****g 的大作中提到】
: 不要google，这里的大牛们有几个知道的举手吧。
: 发现是从1.2就有的类，这么多年我完全没接触过。
|
b******y
发帖数: 1684 | 8 what's the use case, say say ba
【在 F****n 的大作中提到】
: I use it all the time
|
F****n
发帖数: 3271 | 9 1.Cache
2.我比较喜欢用在EventListener里，因为对Event Source来说管理listeners是很
TRICKY的事，比如说A.addListener(B), 如果将来B不用了，就必须CALL A.
removeListener(B), 否则LEAK MEMORY。而如果A把B放在一个WeakReference中就会被
自动回收。
【在 b******y 的大作中提到】
: what's the use case, say say ba
|
m******t
发帖数: 2416 | 10
So whether/when a listener stops getting events is at the mercy of the
garbage
collector?
【在 F****n 的大作中提到】
: 1.Cache
: 2.我比较喜欢用在EventListener里，因为对Event Source来说管理listeners是很
: TRICKY的事，比如说A.addListener(B), 如果将来B不用了，就必须CALL A.
: removeListener(B), 否则LEAK MEMORY。而如果A把B放在一个WeakReference中就会被
: 自动回收。
|
|
|
d*****d
发帖数: 180 | 11 the differences are:
1. when to become a GC candidate..
2. when ref queue gets notified... |
F****n
发帖数: 3271 | 12 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?
|
m******t
发帖数: 2416 | 13
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
发帖数: 3271 | 14 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.
|
s******n
发帖数: 876 | 15 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
|
F****n
发帖数: 3271 | 16
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
发帖数: 876 | 17 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
|
F****n
发帖数: 3271 | 18 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
|
m******t
发帖数: 2416 | 19
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
发帖数: 876 | 20 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.
|
m******t
发帖数: 2416 | 21
Er... I don't think this model/tree/listener thing works the way you think
it does.
【在 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.
|
F****n
发帖数: 3271 | 22 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.
|
