Every thread has a priority. Threads with higher priority are
executed in preference to threads with lower priority. Each thread
may or may not also be marked as a daemon. When code running in
some thread creates a new Thread object, the new
thread has its priority initially set equal to the priority of the
creating thread, and is a daemon thread if and only if the
creating thread is a daemon.
When a Java Virtual Machine starts up, there is usually a single
non-daemon thread (which typically calls the method named
main of some designated class). The Java Virtual
Machine continues to execute threads until either of the following
occurs:
exit method of class Runtime has been
called and the security manager has permitted the exit operation
to take place.
run method or by
throwing an exception that propagates beyond the run
method.
There are two ways to create a new thread of execution. One is to
declare a class to be a subclass of Thread. This
subclass should override the run method of class
Thread. An instance of the subclass can then be
allocated and started. For example, a thread that computes primes
larger than a stated value could be written as follows:
class PrimeThread extends Thread {
long minPrime;
PrimeThread(long minPrime) {
this.minPrime = minPrime;
}
public void run() {
// compute primes larger than minPrime
. . .
}
}
The following code would then create a thread and start it running:
PrimeThread p = new PrimeThread(143);
p.start();
The other way to create a thread is to declare a class that
implements the Runnable interface. That class then
implements the run method. An instance of the class can
then be allocated, passed as an argument when creating
Thread, and started. The same example in this other
style looks like the following:
class PrimeRun implements Runnable {
long minPrime;
PrimeRun(long minPrime) {
this.minPrime = minPrime;
}
public void run() {
// compute primes larger than minPrime
. . .
}
}
The following code would then create a thread and start it running:
PrimeRun p = new PrimeRun(143);
new Thread(p).start();
Every thread has a name for identification purposes. More than one thread may have the same name. If a name is not specified when a thread is created, a new name is generated for it.
Thread object. This constructor has
the same effect as Thread(null, null,
gname), where gname is
a newly generated name. Automatically generated names are of the
form "Thread-"+n, where n is an integer.Thread object. This constructor has
the same effect as Thread(null, target,
gname), where gname is
a newly generated name. Automatically generated names are of the
form "Thread-"+n, where n is an integer.Thread object. This constructor has
the same effect as Thread(group, target,
gname), where gname is
a newly generated name. Automatically generated names are of the
form "Thread-"+n, where n is an integer.Thread object. This constructor has
the same effect as Thread(null, null, name).Thread object. This constructor has
the same effect as Thread(group, null, name)Thread object. This constructor has
the same effect as Thread(null, target, name).Thread object so that it has
target as its run object, has the specified
name as its name, and belongs to the thread group
referred to by group.
If group is null and there is a
security manager, the group is determined by the security manager's
getThreadGroup method. If group is
null and there is not a security manager, or the
security manager's getThreadGroup method returns
null, the group is set to be the same ThreadGroup
as the thread that is creating the new thread.
If there is a security manager, its checkAccess
method is called with the ThreadGroup as its argument.
In addition, its checkPermission
method is called with the
RuntimePermission("enableContextClassLoaderOverride")
permission when invoked directly or indirectly by the constructor
of a subclass which overrides the getContextClassLoader
or setContextClassLoader methods.
This may result in a SecurityException.
If the target argument is not null, the
run method of the target is called when
this thread is started. If the target argument is
null, this thread's run method is called
when this thread is started.
The priority of the newly created thread is set equal to the
priority of the thread creating it, that is, the currently running
thread. The method setPriority may be used to
change the priority to a new value.
The newly created thread is initially marked as being a daemon
thread if and only if the thread creating it is currently marked
as a daemon thread. The method setDaemon may be used
to change whether or not a thread is a daemon.
Thread object so that it has
target as its run object, has the specified
name as its name, belongs to the thread group referred to
by group, and has the specified stack size.
This constructor is identical to with the exception of the fact that it allows the thread stack size to be specified. The stack size is the approximate number of bytes of address space that the virtual machine is to allocate for this thread's stack. The effect of the stackSize parameter, if any, is highly platform dependent.
On some platforms, specifying a higher value for the stackSize parameter may allow a thread to achieve greater recursion depth before throwing a StackOverflowError . Similarly, specifying a lower value may allow a greater number of threads to exist concurrently without throwing an OutOfMemoryError (or other internal error). The details of the relationship between the value of the stackSize parameter and the maximum recursion depth and concurrency level are platform-dependent. On some platforms, the value of the stackSize parameter may have no effect whatsoever.
The virtual machine is free to treat the stackSize parameter as a suggestion. If the specified value is unreasonably low for the platform, the virtual machine may instead use some platform-specific minimum value; if the specified value is unreasonably high, the virtual machine may instead use some platform-specific maximum. Likewise, the virtual machine is free to round the specified value up or down as it sees fit (or to ignore it completely).
Specifying a value of zero for the stackSize parameter will cause this constructor to behave exactly like the Thread(ThreadGroup, Runnable, String) constructor.
Due to the platform-dependent nature of the behavior of this constructor, extreme care should be exercised in its use. The thread stack size necessary to perform a given computation will likely vary from one JRE implementation to another. In light of this variation, careful tuning of the stack size parameter may be required, and the tuning may need to be repeated for each JRE implementation on which an application is to run.
Implementation note: Java platform implementers are encouraged to document their implementation's behavior with respect to the stackSize parameter.
If there is a security manager, its checkAccess method
is called with this thread as its argument. This may result in
throwing a SecurityException.
Note: This method was mistakenly non-final in JDK 1.1. It has been made final in the Java 2 Platform.
enumerate method of the current thread's thread
group with the array argument.
First, if there is a security manager, that enumerate
method calls the security
manager's checkAccess method
with the thread group as its argument. This may result
in throwing a SecurityException.
The equals method implements an equivalence relation
on non-null object references:
x, x.equals(x) should return
true.
x and y, x.equals(y)
should return true if and only if
y.equals(x) returns true.
x, y, and z, if
x.equals(y) returns true and
y.equals(z) returns true, then
x.equals(z) should return true.
x and y, multiple invocations of
x.equals(y) consistently return true
or consistently return false, provided no
information used in equals comparisons on the
objects is modified.
x,
x.equals(null) should return false.
The equals method for class Object implements
the most discriminating possible equivalence relation on objects;
that is, for any non-null reference values x and
y, this method returns true if and only
if x and y refer to the same object
(x == y has the value true).
Note that it is generally necessary to override the hashCode method whenever this method is overridden, so as to maintain the general contract for the hashCode method, which states that equal objects must have equal hash codes.
The threads may be executing while this method is called. The stack trace of each thread only represents a snapshot and each stack trace may be obtained at different time. A zero-length array will be returned in the map value if the virtual machine has no stack trace information about a thread.
If there is a security manager, then the security manager's checkPermission method is called with a RuntimePermission("getStackTrace") permission as well as RuntimePermission("modifyThreadGroup") permission to see if it is ok to get the stack trace of all threads.
First, if there is a security manager, and the caller's class
loader is not null and the caller's class loader is not the same as or
an ancestor of the context class loader for the thread whose
context class loader is being requested, then the security manager's
checkPermission
method is called with a
RuntimePermission("getClassLoader") permission
to see if it's ok to get the context ClassLoader..
If there is a security manager, and this thread is not the current thread, then the security manager's checkPermission method is called with a RuntimePermission("getStackTrace") permission to see if it's ok to get the stack trace.
Some virtual machines may, under some circumstances, omit one or more stack frames from the stack trace. In the extreme case, a virtual machine that has no stack trace information concerning this thread is permitted to return a zero-length array from this method.
java.util.Hashtable.
The general contract of hashCode is:
hashCode method on each of
the two objects must produce the same integer result.
As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects. (This is typically implemented by converting the internal address of the object into an integer, but this implementation technique is not required by the JavaTM programming language.)
This method is designed to allow a program to assert that the current thread already holds a specified lock:
assert Thread.holdsLock(obj);
Unless the current thread is interrupting itself, which is always permitted, the checkAccess method of this thread is invoked, which may cause a SecurityException to be thrown.
If this thread is blocked in an invocation of the wait() , wait(long) , or wait(long, int) methods of the Object class, or of the #join() , #join(long) , #join(long, int) , #sleep(long) , or #sleep(long, int) , methods of this class, then its interrupt status will be cleared and it will receive an InterruptedException .
If this thread is blocked in an I/O operation upon an interruptible
channel
then the channel will be closed, the thread's interrupt
status will be set, and the thread will receive a java.nio.channels.ClosedByInterruptException
.
If this thread is blocked in a java.nio.channels.Selector then the thread's interrupt status will be set and it will return immediately from the selection operation, possibly with a non-zero value, just as if the selector's wakeup method were invoked.
If none of the previous conditions hold then this thread's interrupt status will be set.
millis milliseconds for this thread to
die. A timeout of 0 means to wait forever.millis milliseconds plus
nanos nanoseconds for this thread to die.wait methods.
The awakened thread will not be able to proceed until the current thread relinquishes the lock on this object. The awakened thread will compete in the usual manner with any other threads that might be actively competing to synchronize on this object; for example, the awakened thread enjoys no reliable privilege or disadvantage in being the next thread to lock this object.
This method should only be called by a thread that is the owner of this object's monitor. A thread becomes the owner of the object's monitor in one of three ways:
synchronized statement
that synchronizes on the object.
Class, by executing a
synchronized static method of that class.
Only one thread at a time can own an object's monitor.
wait methods.
The awakened threads will not be able to proceed until the current thread relinquishes the lock on this object. The awakened threads will compete in the usual manner with any other threads that might be actively competing to synchronize on this object; for example, the awakened threads enjoy no reliable privilege or disadvantage in being the next thread to lock this object.
This method should only be called by a thread that is the owner
of this object's monitor. See the notify method for a
description of the ways in which a thread can become the owner of
a monitor.
First, the checkAccess method of this thread is called
with no arguments. This may result in throwing a
SecurityException (in the current thread).
If the thread is alive but suspended, it is resumed and is permitted to make progress in its execution.
Runnable is used
to create a thread, starting the thread causes the object's
run method to be called in that separately executing
thread.
The general contract of the method run is that it may
take any action whatsoever.
First, if there is a security manager, its checkPermission
method is called with a
RuntimePermission("setContextClassLoader") permission
to see if it's ok to set the context ClassLoader..
This method must be called before the thread is started.
This method first calls the checkAccess method
of this thread
with no arguments. This may result in throwing a
SecurityException (in the current thread).
Uncaught exception handling is controlled first by the thread, then by the thread's ThreadGroup object and finally by the default uncaught exception handler. If the thread does not have an explicit uncaught exception handler set, and the thread's thread group (including parent thread groups) does not specialize its uncaughtException method, then the default handler's uncaughtException method will be invoked.
By setting the default uncaught exception handler, an application can change the way in which uncaught exceptions are handled (such as logging to a specific device, or file) for those threads that would already accept whatever "default" behavior the system provided.
Note that the default uncaught exception handler should not usually defer to the thread's ThreadGroup object, as that could cause infinite recursion.
name.
First the checkAccess method of this thread is called
with no arguments. This may result in throwing a
SecurityException.
First the checkAccess method of this thread is called
with no arguments. This may result in throwing a
SecurityException.
Otherwise, the priority of this thread is set to the smaller of
the specified newPriority and the maximum permitted
priority of the thread's thread group.
A thread can take full control of how it responds to uncaught exceptions by having its uncaught exception handler explicitly set. If no such handler is set then the thread's ThreadGroup object acts as its handler.
run method of this thread.
The result is that two threads are running concurrently: the
current thread (which returns from the call to the
start method) and the other thread (which executes its
run method).
It is never legal to start a thread more than once. In particular, a thread may not be restarted once it has completed execution.
If there is a security manager installed, its checkAccess
method is called with this
as its argument. This may result in a
SecurityException being raised (in the current thread).
If this thread is different from the current thread (that is, the current
thread is trying to stop a thread other than itself), the
security manager's checkPermission method (with a
RuntimePermission("stopThread") argument) is called in
addition.
Again, this may result in throwing a
SecurityException (in the current thread).
The thread represented by this thread is forced to stop whatever
it is doing abnormally and to throw a newly created
ThreadDeath object as an exception.
It is permitted to stop a thread that has not yet been started. If the thread is eventually started, it immediately terminates.
An application should not normally try to catch
ThreadDeath unless it must do some extraordinary
cleanup operation (note that the throwing of
ThreadDeath causes finally clauses of
try statements to be executed before the thread
officially dies). If a catch clause catches a
ThreadDeath object, it is important to rethrow the
object so that the thread actually dies.
The top-level error handler that reacts to otherwise uncaught
exceptions does not print out a message or otherwise notify the
application if the uncaught exception is an instance of
ThreadDeath.
If there is a security manager installed, the checkAccess
method of this thread is called, which may result in a
SecurityException being raised (in the current thread).
If this thread is different from the current thread (that is, the current
thread is trying to stop a thread other than itself) or
obj is not an instance of ThreadDeath, the
security manager's checkPermission method (with the
RuntimePermission("stopThread") argument) is called in
addition.
Again, this may result in throwing a
SecurityException (in the current thread).
If the argument obj is null, a
NullPointerException is thrown (in the current thread).
The thread represented by this thread is forced to complete
whatever it is doing abnormally and to throw the
Throwable object obj as an exception. This
is an unusual action to take; normally, the stop method
that takes no arguments should be used.
It is permitted to stop a thread that has not yet been started. If the thread is eventually started, it immediately terminates.
First, the checkAccess method of this thread is called
with no arguments. This may result in throwing a
SecurityException (in the current thread).
If the thread is alive, it is suspended and makes no further progress unless and until it is resumed.
The current thread must own this object's monitor. The thread
releases ownership of this monitor and waits until another thread
notifies threads waiting on this object's monitor to wake up
either through a call to the notify method or the
notifyAll method. The thread then waits until it can
re-obtain ownership of the monitor and resumes execution.
As in the one argument version, interrupts and spurious wakeups are possible, and this method should always be used in a loop:
synchronized (obj) {
while (<condition does not hold>)
obj.wait();
... // Perform action appropriate to condition
}
This method should only be called by a thread that is the owner
of this object's monitor. See the notify method for a
description of the ways in which a thread can become the owner of
a monitor.The current thread must own this object's monitor.
This method causes the current thread (call it T) to place itself in the wait set for this object and then to relinquish any and all synchronization claims on this object. Thread T becomes disabled for thread scheduling purposes and lies dormant until one of four things happens:
A thread can also wake up without being notified, interrupted, or timing out, a so-called spurious wakeup. While this will rarely occur in practice, applications must guard against it by testing for the condition that should have caused the thread to be awakened, and continuing to wait if the condition is not satisfied. In other words, waits should always occur in loops, like this one:
synchronized (obj) {
while (<condition does not hold>)
obj.wait(timeout);
... // Perform action appropriate to condition
}
(For more information on this topic, see Section 3.2.3 in Doug Lea's
"Concurrent Programming in Java (Second Edition)" (Addison-Wesley,
2000), or Item 50 in Joshua Bloch's "Effective Java Programming
Language Guide" (Addison-Wesley, 2001).
If the current thread is interrupted by another thread while it is waiting, then an InterruptedException is thrown. This exception is not thrown until the lock status of this object has been restored as described above.
Note that the wait method, as it places the current thread into the wait set for this object, unlocks only this object; any other objects on which the current thread may be synchronized remain locked while the thread waits.
This method should only be called by a thread that is the owner
of this object's monitor. See the notify method for a
description of the ways in which a thread can become the owner of
a monitor.
This method is similar to the wait method of one
argument, but it allows finer control over the amount of time to
wait for a notification before giving up. The amount of real time,
measured in nanoseconds, is given by:
1000000*timeout+nanos
In all other respects, this method does the same thing as the method of one argument. In particular, wait(0, 0) means the same thing as wait(0).
The current thread must own this object's monitor. The thread releases ownership of this monitor and waits until either of the following two conditions has occurred:
notify method
or the notifyAll method.
timeout
milliseconds plus nanos nanoseconds arguments, has
elapsed.
The thread then waits until it can re-obtain ownership of the monitor and resumes execution.
As in the one argument version, interrupts and spurious wakeups are possible, and this method should always be used in a loop:
synchronized (obj) {
while (<condition does not hold>)
obj.wait(timeout, nanos);
... // Perform action appropriate to condition
}
This method should only be called by a thread that is the owner
of this object's monitor. See the notify method for a
description of the ways in which a thread can become the owner of
a monitor.