or retain references across calls or threads, you will need to convert those local references into
global ones. (By making them global, you are adding a root reference to the objects in question so
they won't get garbage collected or moved.)
In short, if your JVM uses the system's native threads library, every combination of threads and
synchronization should work correctly. If your JVM uses green threads, you should expect things
not to work together.
This is very tricky stuff. Be careful!
A Few Assorted Methods
There are a small number of other methods that provide minor functionality that you probably
won't use. You can ask the JVM how many threads there are currently running in a thread's thread
group [Thread.activeCount()] and which of them is "alive" [Thread.isAlive()]. You
can get a list of them, too [Thread.enumerate()]. Unfortunately, by the time you get around
to using any of this information, it may have changed. If you need to keep track of the threads in
your application, you will need to design an ad hoc mechanism to do so. Just like thread groups,
this is not a big deal and is easily accomplished.
All three of these methods are officially deprecated in Java 1.1 and replaced with the thread
group methods threadsCount(), groupCount(), and allThreads().
Do you need to know how many threads are running? Have them increment a counter upon
starting. Need to know if a thread has completed its work? Use a semaphore or a wait/notify. You
can also change the print string for a thread [setName()].
The default stack size for Java is implementation dependent. On Solaris the default stack is 500k,
which is big enough for 10,000 recursive calls to a method of no arguments and no local variables.
This is probably big enough for any program. You can change the stack size by passing a
command line argument. This invocation will give you a 1-MB stack for all threads:
%java -oss 1000000 Test
If a thread overflows its stack, it will hit a guard page that is mapped in nonreadable. This way
you will get an immediate SEGV so you can go back and fix your program.
You can find out how deep the current stack is [Thread.countStackFrames()] and even
print it out [Thread.dumpStack()].
When a method becomes deprecated (wonderful term, eh?), for how much longer will it be
supported? If you have a program written for JDK 1.1 that uses stop(), do you need to worry
about running it on JDK 1.2?
Search WWH :