Java Development

[hanqiwang]

I run a j2me project in blackberry, it throw "TOO MANY Threads EXCEPTION",I found that some threads are not destroy,but they are destroyed in j2me, how to release or close the thread in blackberry?

[acherry]

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.

[BBDeveloper]

Check this KB article, which tells how many active threads allowed on BB device.

http://www.blackberry.com/knowledgecenterpublic/livelink.exe/fetch/2000/348583/800451/800783/What_Is...

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.

http://supportforums.blackberry.com/rim/board/message?board.id=java_dev&message.id=22018&query.id=96...

[hanqiwang]

We used a thread pool to manage threads. When we want to free a thread, we will set this thread null, it's ok on j2me, but the thread are not free on Blackberry. It seems that there are some difference on thread between j2me and Blackberry.

[marchywka]

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.

[peter_strange]

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.

Message Edited by peter_strange on 03-06-2009 04:02 PM

[marchywka]

An executing thread can reach itself, I'll avoid adding any colorful analogies at this point

http://www.google.com/search?hl=en&q=site%3Asun.com+reachable+thread&btnG=Google+Search&aq=f&oq=

I think he is doing the opposite of lazy initialization to make app more responsive. This would seem to be

the issue. 

[bneeman]

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.

Cheers, Barak.