Re: Object creation vs. ThreadLocal retrieval
- From: NOBODY <antispam@xxxxxxx>
- Date: Fri, 28 Oct 2005 00:18:10 GMT
> I have a method which searches a singly linked list for an object. It
> needs to return references to both the object and the preceding object
> in the list. I have created a very simple inner class to encapsulate
> this information:
>
> private final class MemberReference
> {
> final Member referent;
> final Member previous;
>
> MemberReference(Member referent, Member previous)
> {
> this.referent = referent;
> this.previous = previous;
> }
> }
Note 1: I will assume that this is not clashing with interface
java.lang.reflect.Member.
Note 2: I will suggest you make all your innerclasses static, unless they
actually need their enclosing class which is easy to find with a good
IDE. (private static final class MemberReference)
I'm not sure why you cannot simply have 2 local variable in the loop that
traverses the linked list.
Object prev = null, current = null;
Iterator it=list.iterator();
for(Iterator it=list.iterator(); it.hasNext();) {
prev = current;
current = it.next();
//do stuff, possibly break.
}
You must be going through some 3rd party code that runs your code (some
visitor pattern) for you to need such a hack to return 'prev' and
'current'.
The answer: threadlocal lookup is an order(1) hashmap lookup. That is
pretty fast. I recommend it, even if bad mouths will tell you that with
modern jvm 'new' and garbage collection is faster, is it still CPU that
you don't use when you use a thread local (you use it differently but at
least you use it on every thread, not just a bunch of GC threads).
The 2 other ways around: a static variable (since you are not
multithreaded), but that is always ugly. The other way is only if you
defined your own thread class: you can put a public field/method in the
thread subclass instance that any code can access given a cast of current
thread:
public class MyThread extends Thread {
Object prev;
Object current;
public void setCurrent(Object x) {
prev = current;
current = x;
}
public void clear() {
prev = current = null;
}
}
MyThread t = (MyThread)Thread.currentThread();
t.clear();
Iterator it=list.iterator();
for(Iterator it=list.iterator(); it.hasNext();) {
t.setCurrent(it.next());
//do stuff, possibly break.
}
> An instance of this class will be required for just about every access
> the the class, including reads, which could cause a lot of these
> objects to be created and then discarded.
>
> I'd like to avoid this if possible, but the class does need to support
> reading by multiple threads, so I wouldn't want to use a single
> instance (or a couple of class fields). I'm thinking of using a
> ThreadLocal, but I can't help wondering if retrieving the thread-local
> value might not be more expensive than creating a new object.
>
> Anyone have any experience/thoughts?
>
> Thanks!
>
.
- References:
- Object creation vs. ThreadLocal retrieval
- From: Ian Pilcher
- Object creation vs. ThreadLocal retrieval
- Prev by Date: Re: Opening for WebFOCUS, Cold Fusion, or Microsoft .NET developer
- Next by Date: Re: Getting a date of the remote machine from a Java desktop application
- Previous by thread: Object creation vs. ThreadLocal retrieval
- Next by thread: Re: Object creation vs. ThreadLocal retrieval
- Index(es):
Relevant Pages
|
