遗憾的是，在Java中对字符串使用正则表达式时，无法指定超时。因此，如果您无法严格控制将哪些模式应用于哪个输入，则最终可能会使线程消耗大量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 向我指出这个解决方案，我已经能够解决我原来的问题，而无需额外的线程。我已经在那里发布了代码。感谢所有做出回应的人。
如果你确定 Thread.stop（） 是唯一可用的解决方案，你可以使用它。您可能需要关闭并重新启动应用程序以确保其处于良好状态。
注意：线程可以捕获并忽略ThreadDeath因此不能保证停止停止所有线程。
停止线程的另一种方法是在不同的进程中运行它。这可以根据需要杀死。这仍然可以使资源处于不协调状态（如锁定文件），但不太可能且更容易控制。
当然，最好的解决方案是修复代码，这样它就不会首先这样做，而是尊重 Thread.interrupt（）。
不要使用已弃用的Thread.stop()，而是使用 Thread.interrupt() 它将停止引发可以通过 isInterrupted() 或 interrupted() 检查的中断标志，或抛出InterruptedException。
我构建扩展 Thread 类的模式是这样的
class MyThread extends Thread{
private volatile boolean keepRunning = true;
public void run(){
while(keepRunning){
// do my work
}
}
public void killThread(){
keepRunning = false;
this.interrupt();
}
}
并不是说我的处理方式是完美的，可能会有更好的赌注，但这对我有用。
由如果需要停止的线程没有保留任何（明显的）监视器或对程序其余部分使用的对象的引用，那么使用 Thread#stop（） 是否可以接受？
您决定它是否"可接受"。 我们所能做的就是建议它是否安全。 答案是不是。
它所持有的非明显监视器和引用呢？
否则它会发出的通知等呢？
它可能影响静态的操作呢？
问题在于，很难（在大多数情况下）确定您已经考虑了线程可能与应用程序其余部分进行的所有可能的交互。
重新启动应用程序正是我试图避免的......
我突然意识到，这是你问题的真正根源;也就是说，你设计了一个程序，没有考虑到出于务实的原因需要重新启动长时间运行的程序。 特别是具有潜在错误的复杂那些。
如果您专门将线程代码设计为不持有锁等（是的，这包括非显式锁，例如，更改字符串大小时可能使用的 malloc 锁），则停止线程，是的。轮询"中断"标志是可以的，除了它意味着轮询"中断"标志，即。在 99.9999% 的时间内，开销实际上未设置。 这可能是高性能、紧密循环的问题。
如果检查可以保持在最内层循环之外，并且仍然合理地频繁检查，那么这确实是最好的方法。
如果不能经常检查该标志（例如，由于无法访问的库代码中的紧密循环），您可以将线程优先级设置为尽可能低的优先级并忘记它，直到它最终死亡。
另一个偶尔可能的情况是销毁线程正在处理的数据，使库代码正常退出，导致引发异常，从而控制从不透明的库代码中冒泡或导致调用"OnError"处理程序。 如果库。正在对字符串进行操作，用 null 喷洒字符串肯定会做一些事情。 任何异常都可以 - 如果你可以在线程中安排一个 AV/段错误，那么只要你重新获得控制权，就可以了。