03-05-2009 07:59 PM
03-05-2009 08:36 PM
The only reliable way to 'destroy' a thread in any Java environment is to return from the entry point to the thread, run(). I believe at this point, Thread.stop() Thread.destory() and similar deprecated methods don't do anything at all in most JVM environments.
In addition, be sure that you don't hold ANY references to either the Thread object or any other objects bound to the thread from any other threads or static objects or the thread can't be GCed.
03-06-2009 01:03 AM
Check this KB article, which tells how many active threads allowed on BB device.
You have to minimise the number of threds getting created, or create the threds when the other thred completes its work.
Check this thread, it got some discussion on the simmilar topic.
03-06-2009 07:20 AM
03-06-2009 09:23 AM
I guess "ok" is a matter of degree LOL. Object re-use and pooling are great as new and GC take
up resources. But, in terms of your immediate question, see my earlier comments and links
to sun discussing those methods- they have been deprecated for a long time and are generally not
needed by app programmers.
If you are making a server and need all those threads great but BB and carriers don't allow you
the honor of making your own server and there are really 16 asynchronous worthwhile things
to do. You could consider a queue for activity types and serialize them.
03-06-2009 10:26 AM - edited 03-06-2009 11:02 AM
You said "When we want to free a thread, we will set this thread null".
That doesn't sound like the right way to get rid of a Thread. I think before you set your reference to null, you should really force the Thread to exit its run() method.
I have a sneaking suspicion that the RIM JVM will actually keep a reference to the Threads used by an Application. It will use this to terminate Threads when your Application exits for example (as well as barf when you start more than 16!). Any way, as a result, setting your reference to null will not cause the garbage collector to remove the Thread, hence why this mechanism doesn't work on RIM. I think if you can persuade the run() method to complete, that will return control, presumably to the OS, which will tidy up this reference. I think its the right thing to do and it means your code will work on the BlackBerry and other J2ME phones.
Edit: Forgot to say, in some testing I've done in the past, Threads that have exited their run() methods, but have not been de-referenced, are NOT counted in the Application limit. So a Thread is only counted as one of the 16 while in its run() method.
03-06-2009 10:32 AM
An executing thread can reach itself, I'll avoid adding any colorful analogies at this point
I think he is doing the opposite of lazy initialization to make app more responsive. This would seem to be
03-06-2009 10:49 AM
The JVM keeps references to active threads in its own thread pool. For that reason, an active Thread will never be garbage-collected. Doesn't matter if you keep a reference to it or not.
The only way to get out of the JVM's thread pool is for the Runnable to return from void run(). That's the correct way to terminate a Thread on Blackberry, in J2ME, and any other kind of JAVA.