java让线程停止
① java中终止线程的方法
在Java的多线程编程中，java.lang.Thread类型包含了一些列的方法start(),stop(),stop(Throwable)andsuspend(),destroy()andresume()。通过这些方法，我们可以对线程进行方便的操作，但是这些方法中，只有start()方法得到了保留。本文是海文国际小编搜索整理的关于JAVA中终止线程的方法，供参考复习，希望对大家有所帮助!
如果真的需要终止一个线程，可以使用以下几种方法：
1、让线程的run()方法执行完，线程自然结束。（这种方法最好）
2、通过轮询和共享标志位的方法来结束线程，例如while(flag){},flag的初始值设为真，当需要结束时，java课程培训机构建议将flag的值设为false。（这种方法也不很好，因为如果while(flag){}方法阻塞了，则flag会失效）
② 求教高手：java中如何暂停一个线程中的任务，在以后的可以恢复之前任务的执行。
可以用以下几种方法：
interrupt():中断线程
stop()：强迫线程停止执行。用 Thread.stop 来终止线程将释放它已经锁定的所有监视器（作为沿堆栈向上传播的未检查 ThreadDeath 异常的一个自然后果）。如果以前受这些监视器保护的任何对象都处于一种不一致的状态，则损坏的对象将对其他线程可见，这有可能导致任意的行为。
yield()只是使当前线程重新回到可执行状态，所以执行yield()的线程有可能在进入到可执行状态后马上又被执行。yield()只能使同优先级的线程有执行的机会。----这句是重点
3.书上说yelid()是礼让,是让当前执行线程停下来给别的线程资源, 又说没有任何机制保证会这样。----------没有任何机制保证执行yield()的线程一定会把资源让给其它线程。打个比方：两个人抢东西，A抢到了B没有，再把东西放回去重抢，说不定还是A抢到B没有。没有任何机制保证放回去后B一定能抢到
sleep方法使线程睡眠，但是到一定毫秒数时会自动到cpu中等待
wait方法使线程等待，但是不会自动到cpu中等待，要通过notify或者notifyall方法进行唤醒。
以上是让线程等待的方法，你可以选择适合你程序的方法。
③ Java线程停止的方法，及stop等方法为什么被废弃
在 Java 中有以下 3 种方法可以终止正在运行的线程：
停止一个线程的推荐做法是修改某些变量以指示目标线程应停止运行。 目标线程应定期检查此变量，如果该变量指示要停止运行，则应有序地从其运行方法返回。 这是为了确保对 stop-request 进行及时的通信，变量必须是 volatile 或者必须同步访问变量。
使用 stop 方法终止线程存在本质上的不安全性。停止线程会使它解锁它已锁定的所有监视器，当 ThreadDeath 异常在堆栈中向上传播时，监视器将被解锁。如果先前由这些监视器保护的任何对象处于不一致状态，则其他线程现在可能会以不一致状态查看这些对象，这些对象被称为已损坏的对象。当线程对损坏的对象进行操作时，可能会导致任意行为。与未检查的异常不同，ThreadDeath 会无声地杀死线程，用户没有警告其程序可能已损坏，在实际损坏发生后的任何时间，腐败会体现出来。
为什么 Thread.stop 被废弃? 因为它本质上是不安全的。停止线程会使它解锁它已锁定的所有监视器，这可能导致其他线程以不一致状态查看对象。当线程对损坏的对象进行操作时，可能会导致任意行为。ThreadDeath 异常会无声地杀死线程，用户没有警告其程序可能已损坏，这使得编写正确的多线程代码的任务大大复杂化。
停止等待较长时间的线程（例如，等待输入）可以通过使用 Thread.interrupt 方法来实现。可以使用上面展示的基于状态的信令机制，当状态更改之后可以调用 Thread.interrupt 来中断等待。为了使该技术起作用，至关重要的是，任何捕获中断异常并且不准备处理中断异常的方法都必须立即重新声明该异常。
如果线程不响应 Thread.interrupt，那么确实没有什么技术能奏效。在这种情况下，应该注意的是，在所有等待线程不响应 Thread.interrupt 的情况下，它也不响应 Thread.stop。这种情况下包括故意的拒绝服务攻击，以及 Thread.stop 和 Thread.interrupt 无法正常工作的 I/O 操作。
为什么不赞成使用 Thread.suspend 和 Thread.resume? Thread.suspend 本质上容易死锁。 如果目标线程在挂起时，在监视器上持有一个保护关键系统资源的锁，则在恢复目标线程之前，没有线程可以访问该资源。如果将恢复目标线程的线程在调用 resume 之前尝试锁定此监视器，则会导致死锁。 这种僵局通常表现为“冻结”进程。
应该使用什么代替 Thread.suspend 和 Thread.resume? 谨慎的方法是让“目标线程”轮询一个指示线程所需状态（活动或挂起）的变量。当所需的状态被挂起时，线程使用 Object.wait 等待。恢复线程后，将使用 Object.notify 通知目标线程。
可以结合两种技术来产生可以安全地“停止”或“暂停”的线程。一个微妙之处是目标线程可能在另一个线程试图将其停止时已被挂起。如果 stop 方法仅将状态变量设置为 null，则目标线程将保持挂起状态（在监视器上等待），而不是正常的退出。如果重新启动了 applet，则多个线程可能最终会同时在监视器上等待，从而导致行为不稳定。要纠正这种情况，stop 方法必须确保目标线程在挂起后立即恢复。目标线程恢复后，必须立即识别出它已停止，并正常退出。
关于 Thread.destroy 方法，Thread.destroy 从未真正被实现。如果实现了它，使用 Thread.suspend 容易发生死锁。实际上，它与 Thread.suspend 大致等效，没有后续的 Thread.resume 的可能性。我们目前不实现它，但也不会弃用它（将来将阻止其实现）。尽管肯定会发生死锁，但有人认为，在某些情况下，某个程序愿意冒着 deadlock 的风险也不想直接退出。