javafx 启动 停止多线程 java停止一个线程

要点

• 线程的用法
• 线程的stop方法

• 线程stop过程中存在的问题
• interrupt中断的用法

• 解释清楚使用boolean标志位的好处
• interrupt底层的细节
• 能转移话题到线程安全，并阐述无误

目录

• 如何停止一个线程【概述】
• 为何不能简单地停止一个线程？【为何废弃stop()】
• 协作的任务执行模式【正确停止线程的思路】
• interrupt的原生支持
• interrupt不适用的情况
• interrupted() 与 isInterrupted()的区别
• 中断状态位interrupted_与interrupt()的源码
• boolean标志位方式
• interrupt 与 boolean标志位 两种方式的区别

如何停止一个线程【概述】

【Deprecated v.不赞成的；反对的；】

• 以上是JDK提供的停止线程的方法，
  但是很早就被废弃了；
  主要就是说线程被直接停止掉是不安全，
  涉及到了很多锁之类的细节问题；【下面细说】
  所以不能直接简单地停止线程；
• 需要设计一个方案，
  可以在逻辑上，
  随时中断被取消的任务线程；
  因为物理上没办法简单停止掉了；
  但是我们可以结束掉线程中的任务；

为何不能简单地停止一个线程？【为何废弃stop()】

• 如图，
  假设这里有三个线程，
  左侧CPU、内存、文件视为线程的共享资源；
• 首先聚焦内存，
  线程1在访问内存的时候加了锁，
  为了防止其他线程脏读脏写至于数据不同步的问题；
• 这时候线程3也想要拿到这块内存，申请内存锁，
  这时候内存锁被线程1持有了，
  线程3只能阻塞，等待线程1释放内存锁；
  
  
  



• 
  
• 接着，
  我们暂停线程1，这时候线程1虽然暂停了，
  但是它仍然它仍然持有内存锁；
  线程3还是阻塞，得等；
  万一这时候线程3还有线程1的锁，
  那都死锁了；
  所以就存在很多问题，
  于是线程的暂停和继续的API方法也是被废弃了；
  
  
  



• 
  
  
  



• 
  
• 而假设的话，假设线程1可以被干掉，也就是stop()，
  假设此时线程1被干掉（停止）了，则会立即释放内存锁；
  线程3马上拿到内存锁并加锁，进入就绪状态，等待CPU时间片；
  
  
  



• 随后线程3拿到CPU时间片，便可以被调度而进入运行状态了，
  就开始读取内存，
  这个时候很可能读到莫名其妙的异常数据，
  很可能线程1刚才被干掉的时候，
  还没来得及把内存整理好就被结束了，
  留下来了奇奇怪怪的内存块给线程3；
  这个时候如果线程3还把这个错误的数据拿去实际使用，
  那整个过程就很危险了；
• 到这里我们发现，
  其实一开始线程1就不该允许被简单粗暴地直接停止掉，
  不然只会对后续的进程运行埋下隐患；
  由此，简单粗暴的stop()便被废弃掉了！！！！！！
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

协作的任务执行模式【正确停止线程的思路】

• 通知目标线程自行结束，而不是强制停止
  逻辑上，线程【Thread】往往跟任务【run()】是强绑定的，
  任务执行完了，线程也就“结束”了；
  
  线程虽然无法被干掉，但是任务是可以停止的；
  
  所以要“结束”一个线程，只要想方法，
  结束掉其对应的任务即可！！！
  应该在任务上添加停止逻辑，而不是在线程上添加；
  理解上，
  线程直接被stop干掉，会来不及收拾占有的资源，
  但是如果是自己正常地运行完，便可以好好收拾了；
• 目标线程应当具备处理中断的能力
• 两种中断方式

• Interrupt
• boolean标志位

interrupt的原生支持

• 这里右侧的调用方，
  让主线程休眠2秒，
  是为了确保启动的子线程thread有机会执行一段时间；
  【关于就绪转运行需要时间片的问题】
• 记得我们在开发的时候，
  每次使用sleep()之类的方法，
  AS都让我们使用try...catch捕获InterruptedException吧，
  那便是因为，
  sleep()执行后在睡眠阻塞期间，有可能会收到这个异常；
• 如果线程在sleep()的时候，
  有代码拿着这个线程的引用去调用了interrupt()这个方法，
  那么这个sleep()就会被中断掉，
  这个时候就会抛出中断异常 InterruptedException，
  catch中就可以捕获了，
  然后进行线程“结束”前需要做的相应的操作，
  比如线程之前打开了文件流，占用了什么资源之类的，
  就可以在这里关闭了；

interrupt不适用的情况

• 比如，
  我们在线程里边搞了一个规模较大的循环：
  
  



• 这个时候
  如果在外边使用这个线程的引用去调用它的interrupt()，
  那其实不会对for循环的运行产生影响，
  因为这种情况不支持；
• 如果想让上面的情况支持interrupt()，就得for循环里面加个判断：
  
  



• 每轮循环都判断一遍自己是否被中断了，是则运行结束循环的逻辑(如break;)；
  interrupted()返回true，表示收到了中断；

interrupted() 与 isInterrupted()的区别

• interrupted()是静态方法， 获取当前线程的中断状态，并清空

• 当前运行的线程
• 调用后中断状态清空，
  即如果只有一次interrupt()调用，
  那短时间内，
  第一次调用interrupted()为true，
  第二次调用interrupted()为false；

• isInterrupted()是非静态方法， 获取该线程的中断状态，不清空

• 调用的线程对象对应的线程
• 可重复调用，中断清空前一直返回true；

• 追根究底，可以看一下它们的源码
  
  



• 看一下这个JNIEnv\*引用，它有一个成员self，self其实就是底层线程的对象；
  这里调用了self的Interrupted()；
  
  isInterrupted()的源码呢，
  isInterrupted()既然是一个非静态方法，
  那它的底层是需要引用到其对应的一个Java线程对象【java_thread】的；
  所以isInterrupted()被调用的时候，
  它的底层首先是找到java_thread对应的C++底层thread实例，
  之后使用这个底层thread实例去掉用它的IsInterrupted()；
• 再往底层去，
  看一下底层的Interrupted()和IsInterrupted()，
  【区别于Java层的interrupted()和isInterrupted()】
  可以看到实际上，
  Interrupted()中除了多了一句清空当前中断状态的代码之外，
  其他的实际跟IsInterrupted()都是一样，
  最后都是返回IsInterruptedLocked()：
  
  

中断状态位interrupted_与interrupt()的源码

• 这个中断状态实际上是底层的一个布尔值，即interrupted_；
  它还被一个叫wait_mutex_的东西加了一个锁，
  为了保证读的过程中是线程安全的；
  
  

  

• interrupt()的源码本质，
  就是对self【java线程对应的底层线程的对象】加了个锁，
  然后把中断状态位interrupted_置为true；
  
  

  

boolean标志位方式

• 线程类中定义一个布尔值，
  并且在需要的地方，如每一轮for循环中，
  不断判断这个值，看看是否要被中断任务，
  外部可以通过改动这个值来使得线程的任务发生中断；
  
  
  



• 
  
• 有点类似于interrupted()方式的逻辑，
  区别在于interrupted()和isInterrupted()访问并返回的那个interrupted_位刚刚说了，
  它是有加锁了的，保证了线程安全；
  所以这里同样是要保证我们定义的这个布尔值变量的可见性才行，
  【不然外部改动了这个值，线程类实例中不一定能看得到！！！！！】
  这里给这个布尔值变量加上volatile关键词，
  要求其他地方改动了这个变量，线程类实例中能够马上知晓，
  保证可见性：
  
  
  



• 
  

interrupt 与 boolean标志位 两种方式的区别

• interrupt可以操作系统方法（如sleep）的中断，
  boolean标志位 不可；
• interrupt涉及到了JNI底层的方法逻辑调用【开销大于 boolean标志位 】，
  boolean标志位 没有；
• interrupt 底层标志位默认加锁，
  boolean标志位 没有，要 自己加；
• interrupt 的触发方式， 系统方法是自动抛异常，
  非系统方法 则需要我们调用interrupted()与 isInterrupted()做布尔值判断；
  boolean标志位 的触发方式，
  抛异常 还是 布尔值判断，就都可以，自己定了；

如果需要支持系统方法，
则应当用interrupt的方式，别无选择；

其他情况可以优先考虑 boolean标志位，
因为上面也说了，它性能比较好，
没有太多JNI细节羁绊；

---

参考

• 慕课网
• InterruptedException异常处理【有demo】