Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
At the base of my questions is the JVM process and thread behavior. I understand that on most platforms, the JVM runs as a
single process and any threads created "belong" to that single process. This gives rise to a few questions:
Let's establish some terminology before we get down to specifics. First, the Java virtual machine isn't a runnable program,
it's a specification. A program that implements the specification is a Java runtime. The JVM specification loosely defines
what threading features a runtime must support, but does not mandate a particular implementation. Think of the JVM as an interface,
and a runtime as an object that implements that interface.
Two implementations that Sun offers are green threads and native threads. Green-threads Java runtimes don't require the underlying operating systems to support threads -- the runtime handles scheduling, preemption, and all other thread-related tasks all by itself. One disadvantage to this scheme is that it cannot distribute threads across several CPUs, so it doesn't take advantage of multi-CPU computers. Native-threads Java runtimes only run on operating systems that directly support threads. The OS is free to distribute threads across CPUs, but it is also free to use whatever scheduling algorithms it wishes, taking control away from the developer.
Now, on to your specific questions:
Can multiple threads overload the main process and cause it to crash?
In practice, a program will run out of memory long before it reaches any kind of thread limit. (Just for fun, the Java Q&A experts wrote a program that did nothing but create new threads, and ran it on an UltraSparc 2 with 128 MB of RAM. After
the program created 10,000 threads, we became bored and gave up.) Keep in mind that each thread takes up a small but measurable
amount of system resource like memory, so threads shouldn't be created willy-nilly.
Can threads be started, suspended, and otherwise managed like processes can?
If you want to know if you can, from your terminal, look at a list of running threads and selectively kill them, the answer
is no. If you're asking if one thread in a process can get a list of threads in the same process and selectively kill them,
The answer is yes. There are four lifecycle methods in the java.lang.Thread class -- start() and stop(); suspend() and resume(). The start() method is fine, but suspend() and stop() should be avoided if at all possible. Here's a code snippet from a runnable to demonstrate why these two methods are bad:
public void run()
{
while (true)
{
Socket s = acceptRequest();
Connection c = getDatabaseConnection();
fulfillRequest(s, c);
reclaimResources(s, c);
}
}
Now, what would happen if this thread were stop()ped after it had opened a socket and a JDBC connection, but before it could close them? Those resources might not be closed
cleanly. Even worse, what would happen if the thread were suspend()ed while creating the JDBC connection? It would keep any locks it held until it was resume()d, which (depending on the JDBC driver) might prevent any other thread from communicating with the database! The suspend() and stop() methods are just too dangerous to use. Instead, rewrite the code as follows: