출처:java.sun.com
 | Why Are Thread.stop, Thread.suspend,
Thread.resume and Runtime.runFinalizersOnExit Deprecated? |
Why is Thread.stop deprecated?
Because it is inherently unsafe. Stopping a thread causes it to unlock all the monitors that it has locked. (The monitors are unlocked as the
ThreadDeath exception propagates up the stack.) If any of the objects previously protected by these monitors were in an inconsistent state, other threads may now view these objects in an inconsistent state. Such objects are said to be
damaged. When threads operate on damaged objects, arbitrary behavior can result. This behavior may be subtle and difficult to detect, or it may be pronounced. Unlike other unchecked exceptions,
ThreadDeath kills threads silently; thus, the user has no warning that his program may be corrupted. The corruption can manifest itself at any time after the actual damage occurs, even hours or days in the future.
Couldn't I just catch the ThreadDeath exception and fix the damaged object?
In theory, perhaps, but it would
vastly complicate the task of writing correct multithreaded code. The task would be nearly insurmountable for two reasons:
- A thread can throw a
ThreadDeath exception almost anywhere. All synchronized methods and blocks would have to be studied in great detail, with this in mind. - A thread can throw a second
ThreadDeath exception while cleaning up from the first (in the catch or finally clause). Cleanup would have to repeated till it succeeded. The code to ensure this would be quite complex.
In sum, it just isn't practical.
What about Thread.stop(Throwable)?
In addition to all of the problems noted above, this method may be used to generate exceptions that its target thread is unprepared to handle (including checked exceptions that the thread could not possibly throw, were it not for this method). For example, the following method is behaviorally identical to Java's
throw operation, but circumvents the compiler's attempts to guarantee that the calling method has declared all of the checked exceptions that it may throw: static void sneakyThrow(Throwable t) {
Thread.currentThread().stop(t);
}
What should I use instead of Thread.stop?
Most uses of
stop should be replaced by code that simply modifies some variable to indicate that the target thread should stop running. The target thread should check this variable regularly, and return from its run method in an orderly fashion if the variable indicates that it is to stop running. (This is the approach that JavaSoft's
Tutorial has always recommended.) To ensure prompt communication of the stop-request, the variable must be
volatile (or access to the variable must be synchronized). For example, suppose your applet contains the following
start,
stop and
run methods: private Thread blinker;
public void start() {
blinker = new Thread(this);
blinker.start();
}
public void stop() {
blinker.stop(); // UNSAFE!
}
public void run() {
Thread thisThread = Thread.currentThread();
while (true) {
try {
thisThread.sleep(interval);
} catch (InterruptedException e){
}
repaint();
}
}You can avoid the use of
Thread.stop by replacing the applet's
stop and
run methods with:
private volatile Thread blinker;
public void stop() {
blinker = null;
}
public void run() {
Thread thisThread = Thread.currentThread();
while (blinker == thisThread) {
try {
thisThread.sleep(interval);
} catch (InterruptedException e){
}
repaint();
}
}
How do I stop a thread that waits for long periods (e.g., for input)?
That's what the
Thread.interrupt method is for. The same "state based" signaling mechanism shown above can be used, but the state change (
blinker = null, in the previous example) can be followed by a call to
Thread.interrupt, to interrupt the wait: public void stop() {
Thread moribund = waiter;
waiter = null;
moribund.interrupt();
}For this technique to work, it's critical that any method that catches an interrupt exception and is not prepared to deal with it immediately reasserts the exception. We say
reasserts rather than
rethrows, because it is not always possible to rethrow the exception. If the method that catches the
InterruptedException is not declared to throw this (checked) exception, then it should "reinterrupt itself" with the following incantation:
Thread.currentThread().interrupt();This ensures that the Thread will reraise the
InterruptedException as soon as it is able.
What if a thread doesn't respond to Thread.interrupt?
In some cases, you can use application specific tricks. For example, if a thread is waiting on a known socket, you can close the socket to cause the thread to return immediately. Unfortunately, there really isn't any technique that works in general.
It should be noted that in all situations where a waiting thread doesn't respond to Thread.interrupt, it wouldn't respond to Thread.stop either. Such cases include deliberate denial-of-service attacks, and I/O operations for which thread.stop and thread.interrupt do not work properly.
Why are Thread.suspend and Thread.resume deprecated?
Thread.suspend is inherently deadlock-prone. If the target thread holds a lock on the monitor protecting a critical system resource when it is suspended, no thread can access this resource until the target thread is resumed. If the thread that would resume the target thread attempts to lock this monitor prior to calling
resume, deadlock results. Such deadlocks typically manifest themselves as "frozen" processes.
What should I use instead of Thread.suspend and Thread.resume?
As with
Thread.stop, the prudent approach is to have the "target thread" poll a variable indicating the desired state of the thread (active or suspended). When the desired state is suspended, the thread waits using
Object.wait. When the thread is resumed, the target thread is notified using
Object.notify. For example, suppose your applet contains the following mousePressed event handler, which toggles the state of a thread called
blinker: private boolean threadSuspended;
Public void mousePressed(MouseEvent e) {
e.consume();
if (threadSuspended)
blinker.resume();
else
blinker.suspend(); // DEADLOCK-PRONE!
threadSuspended = !threadSuspended;
}You can avoid the use of
Thread.suspend and
Thread.resume by replacing the event handler above with:
public synchronized void mousePressed(MouseEvent e) {
e.consume();
threadSuspended = !threadSuspended;
if (!threadSuspended)
notify();
}and adding the following code to the "run loop":
synchronized(this) {
while (threadSuspended)
wait();
}The
wait method throws the
InterruptedException, so it must be inside a
try ... catch clause. It's fine to put it in the same clause as the
sleep. The check should follow (rather than precede) the
sleep so the window is immediately repainted when the the thread is "resumed." The resulting
run method follows:
public void run() {
while (true) {
try {
Thread.currentThread().sleep(interval);
synchronized(this) {
while (threadSuspended)
wait();
}
} catch (InterruptedException e){
}
repaint();
}
}Note that the
notify in the
mousePressed method and the
wait in the
run method are inside
synchronized blocks. This is required by the language, and ensures that
wait and
notify are properly serialized. In practical terms, this eliminates race conditions that could cause the "suspended" thread to miss a
notify and remain suspended indefinitely.
While the cost of synchronization in Java is decreasing as the platform matures, it will never be free. A simple trick can be used to remove the synchronization that we've added to each iteration of the "run loop." The synchronized block that was added is replaced by a slightly more complex piece of code that enters a synchronized block only if the thread has actually been suspended: if (threadSuspended) {
synchronized(this) {
while (threadSuspended)
wait();
}
}In the absence of explicit synchronization,
threadSuspended must be made
volatile to ensure prompt communication of the suspend-request.
The resulting
run method is:
private boolean volatile threadSuspended;
public void run() {
while (true) {
try {
Thread.currentThread().sleep(interval);
if (threadSuspended) {
synchronized(this) {
while (threadSuspended)
wait();
}
}
} catch (InterruptedException e){
}
repaint();
}
}
Can I combine the two techniques to produce a thread that may be safely "stopped" or "suspended"?
Yes; it's reasonably straightforward. The one subtlety is that the target thread may already be suspended at the time that another thread tries to stop it. If the
stop method merely sets the state variable (
blinker) to null, the target thread will remain suspended (waiting on the monitor), rather than exiting gracefully as it should. If the applet is restarted, multiple threads could end up waiting on the monitor at the same time, resulting in erratic behavior.
To rectify this situation, the
stop method must ensure that the target thread resumes immediately if it is suspended. Once the target thread resumes, it must recognize immediately that it has been stopped, and exit gracefully. Here's how the resulting
run and
stop methods look: public void run() {
Thread thisThread = Thread.currentThread();
while (blinker == thisThread) {
try {
thisThread.sleep(interval);
synchronized(this) {
while (threadSuspended && blinker==thisThread)
wait();
}
} catch (InterruptedException e){
}
repaint();
}
}
public synchronized void stop() {
blinker = null;
notify();
}If the
stop method calls
Thread.interrupt, as described above, it needn't call
notify as well, but it still must be synchronized. This ensures that the target thread won't miss an interrupt due to a race condition.
What about Thread.destroy?
Thread.destroy has never been implemented. If it were implemented, it would be deadlock-prone in the manner of
Thread.suspend. (In fact, it is roughly equivalent to
Thread.suspend without the possibility of a subsequent
Thread.resume.) We are not implementing it at this time, but neither are we deprecating it (forestalling its implementation in future). While it would certainly be deadlock prone, it has been argued that there may be circumstances where a program is willing to risk a deadlock rather than exit outright.
Why is Runtime.runFinalizersOnExit deprecated?
Because it is inherently unsafe. It may result in finalizers being called on live objects while other threads are concurrently manipulating those objects, resulting in erratic behavior or deadlock. While this problem could be prevented if the class whose objects are being finalized were coded to "defend against" this call, most programmers do
not defend against it. They assume that an object is dead at the time that its finalizer is called.
Further, the call is not "thread-safe" in the sense that it sets a VM-global flag. This forces
every class with a finalizer to defend against the finalization of live objects!
 |
2004-05-21 03:20:40.0 (papilla 220.122.230.33) D |
영어에 약하신 분들과, 명확한 이유를 한 눈에 알기 원하시는 분들을 위해서 말씀 드립니다.
Thread가 suspend되었을 당시의 그 Thread가 수행하던 프로시져의 상황을 판단하고 표현할수 있는 기준이 없기 때문입니다. 따라서 프로그래머는 스레드가 정지되는 시점의 상황을 예측하는 것이 불가능합니다. 예를 들어 Thread가 다른 객체나 스레드와 어떠한 동일한 참조를 가지고 있을 경우, Thread가 재개되었을 경우,Thread가 서스펜드 되었을 때와 완전히 같은 상태를 가진다고 보장할 수 없습니다.
또한 Thread가 어떤 독점 자원을 물고 있는 상태에서 서스펜드 된다면 (예를 들어 쓰레드 내부에서 synchronized함수를 호출하고 그 프로시져가 진행되던 도중 suspended된다면) 다른 모든 스레드는 그 자원을 사용할 수 없게 될 것입니다.
결국 Sun은 프로그래머가 Thread를 상속받아 자기 자신만의 Thread를 만들 되, 스스로 Thread가 안전한 장소(프로그래머가 예측할 수 있는)에서 suspend될 수 있도록 (예를 들면 synchronized된 메소드를 호출한경우, 그것을 전부 호출 한 다음에야 suspend된다거나 하는 식의)직접 플래그와 판단 조건과, 스레드의 상태를 추상화 하라고 권고 하는 것입니다.
여기에 대한 자세한 정보가 필요하다면 운영체제론을 다룬 아무 기술서적을 살펴 보더라도 등장할 것입니다. deadlock을 다룬 부분을 찾아 보세요.
ps. 일반적으로 스레드는 절대 서스펜드 될 필요가 될 수 없게끔 전체 스레드 모델을 잘 설계하고 디자인 하는 것이 훨씬 더 중요합니다.
Java Software 
[2004년 4월 19일] 자바 기술을 이용하여 사인드 애플릿 만들기!!!! 
