Java Thread Primitive Deprecation
来源:互联网 发布:免费注册淘宝会员 编辑:程序博客网 时间:2024/04/19 02:53
Java Thread Primitive Deprecation
Why is Thread.stop
deprecated?
Because it is inherently unsafe. Stopping a thread causes it tounlock all the monitors that it has locked. (The monitors are unlocked as theThreadDeath
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
exceptionand fix the damaged object?(如果不捕获ThreadDeath,该线程会终止运行,并且不会在终端报任何错误,但是也可以捕获住,这样线程就不会终止运行
)
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 thecatch
orfinally
clause). Cleanup would have to repeated till it succeeded. The code to ensure this would be quite complex.
What about Thread.stop(Throwable)
?
In addition to all of the problems noted above, this method maybe used to generate exceptions that its target thread is unpreparedto 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'sthrow
operation, but circumvents the compiler'sattempts 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. 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() { while (true) { try { Thread.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 { Thread.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 toThread.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 awaiting thread doesn't respond toThread.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 dead locks 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 calledblinker
:
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 atry... 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 thread is "resumed." The resultingrun
method follows:public void run() { while (true) { try { Thread.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 areinside synchronized
blocks. This is required by thelanguage, and ensures thatwait
andnotify
are properly serialized. In practical terms,this eliminates race conditions that could cause the "suspended"thread to miss anotify
and remain suspendedindefinitely.While the cost of synchronization in Java is decreasing as theplatform matures, it will never be free. A simple trick can be usedto remove the synchronization that we've added to each iteration ofthe "run loop." The synchronized block that was added is replacedby a slightly more complex piece of code that enters a synchronizedblock only if the thread has actually been suspended:
if (threadSuspended) { synchronized(this) { while (threadSuspended) wait(); } }
In the absence of explicit synchronization,threadSuspended must be madevolatile to ensureprompt communication of the suspend-request.
The resultingrun
method is:private volatile boolean threadSuspended; public void run() { while (true) { try { Thread.sleep(interval); if (threadSuspended) { synchronized(this) { while (threadSuspended) wait(); } } } catch (InterruptedException e){ } repaint(); } }
Can I combine the two techniques to produce a thread that maybe safely "stopped" or "suspended"?
Yes, it's reasonably straightforward. The one subtlety is that thetarget thread may already be suspended at the time that anotherthread tries to stop it. If thestop method merely setsthe state variable (blinker) to null, the target threadwill remain suspended (waiting on the monitor), rather than exitinggracefully as it should. If the applet is restarted, multiplethreads could end up waiting on the monitor at the same time,resulting in erratic behavior.To rectify this situation, the stop method must ensurethat the target thread resumes immediately if it is suspended. Oncethe target thread resumes, it must recognize immediately that ithas been stopped, and exit gracefully. Here's how the resultingrun and stop methods look:
public void run() { Thread thisThread = Thread.currentThread(); while (blinker == thisThread) { try { Thread.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, asdescribed above, it needn't callnotify as well, but itstill must be synchronized. This ensures that the target threadwon't miss an interrupt due to a race condition.
What about Thread.destroy
?
Thread.destroy
was never implemented and has beendeprecated. If it were implemented, it would be deadlock-prone inthe manner ofThread.suspend
. (In fact, it is roughlyequivalent toThread.suspend
without the possibilityof a subsequentThread.resume
.)Why is Runtime.runFinalizersOnExit
deprecated?
Because it is inherently unsafe. It may result in finalizers beingcalled on live objects while other threads are concurrentlymanipulating those objects, resulting in erratic behavior ordeadlock. While this problem could be prevented if the class whoseobjects are being finalized were coded to "defend against" thiscall, most programmers donot defend against it. They assumethat an object is dead at the time that its finalizer is called.Further, the call is not "thread-safe" in the sense that it setsa VM-global flag. This forcesevery class with a finalizerto defend against the finalization of live objects!
- Java Thread Primitive Deprecation
- Java Primitive
- 在JAVA中注解@SuppressWarnings("deprecation")的Deprecation是什么意思
- java primitive 数据类型长度
- [Java] Primitive 类型
- [Java] Primitive(原始) 类型
- java基础primitive 类型
- Java编程问题——@SuppressWarnings("deprecation")
- Java sort 源码解析 primitive part
- java 关于primitive数组 内存问题
- Java的原始类型(Primitive Type)
- Thinking in java (2)----primitive types
- java的primitive主数据类型和引用
- Java的原始类型(Primitive Type)
- @SuppressWarnings("deprecation")
- Thread & Java
- Java Thread
- java Thread
- 初识ZigBee Update
- 一步步学习微软InfoPath2010和SP2010--第一章节--介绍InfoPath2010
- jsp上传图片
- js中数组的排序
- hbase 运维
- Java Thread Primitive Deprecation
- ubuntu 安装 java7
- Burrows–Wheeler transform
- FFmepg 多线程解码历程 - 2 :avcodec_decode_video2
- Eclipse Tomcat 内存不足:Caused by: java.lang.OutOfMemoryError: Java heap space
- 华为等手机无法打印调试LOG的解决方法
- IE6不支持position:fixed问题
- android:maxLines="2" android:ellipsize="end"
- 递归算法