遗憾的是，在Java中对String使用正则表达式时无法指定超时。因此，如果您没有严格控制哪些模式应用于哪个输入，您可能最终会拥有消耗大量CPU的线程，同时无休止地尝试匹配（不是那么精心设计）模式（恶意？）输入。
我知道不推荐使用Thread＃stop（）的原因（参见http://download.oracle.com/javase/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html）。它们以可能在ThreadDeath异常情况下被破坏的对象为中心，然后污染正在运行的JVM环境并导致细微的错误。
对于那些比我更深入了解JVM工作的人，我的问题是：如果需要停止的线程没有任何（明显的）监视器或对由程序的其余部分，然后可以接受使用Thread＃stop（）吗？
我创建了一个相当防御的解决方案，能够处理与超时匹配的正则表达式。我会很高兴任何评论或评论，尤其是尽管我努力避免它们，但这种方法可能导致的问题。
谢谢！
import java.util.concurrent.Callable;
public class SafeRegularExpressionMatcher {
// demonstrates behavior for regular expression running into catastrophic backtracking for given input
public static void main(String[] args) {
SafeRegularExpressionMatcher matcher = new SafeRegularExpressionMatcher(
"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", "(x+x+)+y", 2000);
System.out.println(matcher.matches());
}
final String stringToMatch;
final String regularExpression;
final int timeoutMillis;
public SafeRegularExpressionMatcher(String stringToMatch, String regularExpression, int timeoutMillis) {
this.stringToMatch = stringToMatch;
this.regularExpression = regularExpression;
this.timeoutMillis = timeoutMillis;
}
public Boolean matches() {
CallableThread<Boolean> thread = createSafeRegularExpressionMatchingThread();
Boolean result = tryToGetResultFromThreadWithTimeout(thread);
return result;
}
private CallableThread<Boolean> createSafeRegularExpressionMatchingThread() {
final String stringToMatchForUseInThread = new String(stringToMatch);
final String regularExpressionForUseInThread = new String(regularExpression);
Callable<Boolean> callable = createRegularExpressionMatchingCallable(stringToMatchForUseInThread,
regularExpressionForUseInThread);
CallableThread<Boolean> thread = new CallableThread<Boolean>(callable);
return thread;
}
private Callable<Boolean> createRegularExpressionMatchingCallable(final String stringToMatchForUseInThread,
final String regularExpressionForUseInThread) {
Callable<Boolean> callable = new Callable<Boolean>() {
public Boolean call() throws Exception {
return Boolean.valueOf(stringToMatchForUseInThread.matches(regularExpressionForUseInThread));
}
};
return callable;
}
private Boolean tryToGetResultFromThreadWithTimeout(CallableThread<Boolean> thread) {
startThreadAndApplyTimeout(thread);
Boolean result = processThreadResult(thread);
return result;
}
private void startThreadAndApplyTimeout(CallableThread<Boolean> thread) {
thread.start();
try {
thread.join(timeoutMillis);
} catch (InterruptedException e) {
throwRuntimeException("Interrupt", e);
}
}
private Boolean processThreadResult(CallableThread<Boolean> thread) {
Boolean result = null;
if (thread.isAlive()) {
killThread(thread); // do not use anything from the thread anymore, objects may be damaged!
throwRuntimeException("Timeout", null);
} else {
Exception exceptionOccurredInThread = thread.getException();
if (exceptionOccurredInThread != null) {
throwRuntimeException("Exception", exceptionOccurredInThread);
} else {
result = thread.getResult();
}
}
return result;
}
private void throwRuntimeException(String situation, Exception e) {
throw new RuntimeException(situation + " occured while applying pattern /" + regularExpression + "/ to input '"
+ stringToMatch + " after " + timeoutMillis + "ms!", e);
}
/**
* This method uses {@link Thread#stop()} to kill a thread that is running wild. Although it is acknowledged that
* {@link Thread#stop()} is inherently unsafe, the assumption is that the thread to kill does not hold any monitors on or
* even references to objects referenced by the rest of the JVM, so it is acceptable to do this.
*
* After calling this method nothing from the thread should be used anymore!
*
* @param thread Thread to stop
*/
@SuppressWarnings("deprecation")
private static void killThread(CallableThread<Boolean> thread) {
thread.stop();
}
private static class CallableThread<V> extends Thread {
private final Callable<V> callable;
private V result = null;
private Exception exception = null;
public CallableThread(Callable<V> callable) {
this.callable = callable;
}
@Override
public void run() {
try {
V result = compute();
setResult(result);
} catch (Exception e) {
exception = e;
} catch (ThreadDeath e) {
cleanup();
}
}
private V compute() throws Exception {
return callable.call();
}
private synchronized void cleanup() {
result = null;
}
private synchronized void setResult(V result) {
this.result = result;
}
public synchronized V getResult() {
return result;
}
public synchronized Exception getException() {
return exception;
}
}
}
编辑：
感谢dawce指出我this solution我已经能够解决原始问题，而无需额外的线程。我在那里发布了代码。感谢所有回复的人。
答案 0 :(得分：9)
如果您确定了唯一可用的解决方案，则可以使用Thread.stop（）。您可能需要关闭并重新启动应用程序以确保其处于良好状态。
注意：线程可以捕获并忽略ThreadDeath，因此不保证停止所有线程。
停止线程的另一种方法是在不同的进程中运行它。这可以根据需要杀死。这仍然可以使资源处于不稳定状态（如锁定文件），但它不太可能且更容易控制。
当然，最好的解决方案是修复代码，使其首先不执行此操作并改为使用Thread.interrupt（）。
答案 1 :(得分：2)
如果需要停止的线程没有任何（明显的）监视器或对程序其余部分使用的对象的引用，那么是否可以使用Thread＃stop（）呢？
由你决定来决定它是否“可接受”。我们所能做的就是建议它是否安全。答案是答案不是。
它所持有的非显而易见的监视器和引用呢？
如果通知会发生什么呢？
它可能会影响静力学的行动呢？
问题在于（在大多数情况下）很难确定您已经考虑了线程可能与应用程序其余部分之间可能存在的所有交互。
重启应用程序正是我试图避免的......
让我觉得 是你问题的真正根源;即你设计了一个程序而没有考虑到长时间运行的程序因实际原因需要重新启动的事实。特别复杂，有潜在的错误。
答案 2 :(得分：1)
使用Thread.stop()而不是使用已弃用的Thread.interrupt()，而使用停止来引发中断标志，可以通过isInterrupted()或{{1}进行检查}或抛出interrupted()。
我构建扩展Thread类的模式就像这样
InterruptedException我不是说我处理它的方式是完美的，可能会更好，但这对我有用。
答案 3 :(得分：1)
如果你专门设计你的线程代码没有持有锁等，（是的，这包括非显式锁。例如，更改字符串大小时可能使用的malloc锁），然后停止线程，是的。轮询“中断”标志是好的，除了它意味着轮询“中断”标志，即。在99.9999％的时间内没有实际设置的开销。这可能是高性能，紧密循环的问题。
如果检查可以保持在最里面的循环之外并且仍然可以合理地检查，那么这确实是最好的方法。
如果无法经常检查该标志（例如，由于无法访问的库代码中的紧密循环），您可以将线程优先级设置为尽可能低的值并将其忘记，直到它最终死亡。
偶尔可能的另一个小问题是破坏线程正在工作的数据，使库代码正常退出，导致引发异常，从而控制不透明库代码中的气泡或导致要调用的'OnError'处理程序。如果是lib。正在对一个字符串进行操作，用空值将字符串splatting肯定会做一些事情。任何例外情况都会发生 - 如果您可以在线程中安排AV /段错误，那么只要您获得控制权就可以了。