strategy using the tools in this book, the subtleties of the memory model will work for you and your code will
be fine.
14.11. Thread Management, Security, and THReadGroup
When you're programming multiple threadssome of them created by library classesit can be useful to organize
them into related groups, manage the threads in a group as a unit, and, if necessary, place limitations on what
threads in different groups can do.
Threads are organized into thread groups for management and security reasons. A thread group can be
contained within another thread group, providing a hierarchyoriginating with the top-level or system thread
group. Threads within a group can be managed as a unit, for example, by interrupting all threads in the group
at once, or placing a limit on the maximum priority of threads in a group. The thread group can also be used to
define a security domain. Threads within a thread group can generally modify other threads in that group,
including any threads farther down the hierarchy. In this context "modifying" means invoking any method that
could affect a thread's behaviorsuch as changing its priority, or interrupting it. However, an application can
define a security policy that prevents a thread from modifying threads outside of its group. Threads within
different thread groups can also be granted different permissions for performing actions within the
application, such as performing I/O.
Generally speaking, security-sensitive methods always check with any installed security manager before
proceeding. If the security policy in force forbids the action, the method throws a SecurityException.
By default there is no security manager installed when an application starts. If your code is executed in the
context of another application, however, such as an applet within a browser, you can be fairly certain that a
security manager has been installed. Actions such as creating threads, controlling threads, performing I/O, or
terminating an application, are all security sensitive. For further details, see "Security" on page 677.
Every thread belongs to a thread group. Each thread group is represented by a ThreadGroup object that
describes the limits on threads in that group and allows the threads in the group to be interacted with as a
group. You can specify the thread group for a new thread by passing it to the thread constructor. By default
each new thread is placed in the same thread group as that of the thread that created it, unless a security
manager specifies differently. For example, if some event-handling code in an applet creates a new thread, the
security manager can make the new thread part of the applet thread group rather than the system thread group
of the event-processing thread. When a thread terminates, the Thread object is removed from its group and
so may be garbage collected if no other references to it remain.
There are four Thread constructors that allow you to specify the ThreadGroup of the thread. You saw
three of them on page 343 when looking at Runnable. The fourth is:
publicThread(ThreadGroup group, String name)Constructs a new thread in the specified thread group with the given name.To prevent threads from being created in arbitrary thread groups (which would defeat the security
mechanism), these constructors can themselves throw SecurityException if the current thread is not
permitted to place a thread in the specified thread group.
The ThreadGroup object associated with a thread cannot be changed after the thread is created. You can
get a thread's group by invoking its getThreadGroup method. You can also check whether you are
allowed to modify a THRead by invoking its checkAccess method, which throws
SecurityException if you cannot modify the thread and simply returns if you can (it is a void method).