【安卓小叙】Kotlin多线程编程（一）

Kotlin这是版本，其他与原版相同

线程基础

为何要使用多线程？

• 多线程可以减少程序响应时间。如果某操作很耗时，可以再“后台（其他线程）”执行这个操作，而不至于让程序无法响应。
• 与进程相比，线程创建和切换开销更小，多线程在数据共享方面效率很高。
• 多线程有利于提高CPU使用效率。
• 简化程序结构，便于维护。

创建线程几个方法

继承Thread，重写run方法

  Thread本身也是实现Runnable接口的一个实例。这样，只需要定义Thread的子类，重写run方法以执行需要的任务，然后实例化子类，就可以启用线程。

object Main
{
	@JvmStatic
	fun main(args: Array<String>)
	{
		MyThread().start()
	}

	class MyThread : Thread()
	{
		override fun run()
		{
			super.run()
			println("Frank Miles")
		}
	}
}

实现Runnable接口，并实现run接口

 有两种，一是匿名接口，而是自定义类实现runnable接口。
匿名接口：

object Main
{
	@JvmStatic
	fun main(args: Array<String>)
	{
		thread { 
			// TODO
		}
	}
}

当然，这是简便写法，它源码是：

public fun thread(
    start: Boolean = true,
    isDaemon: Boolean = false,
    contextClassLoader: ClassLoader? = null,
    name: String? = null,
    priority: Int = -1,
    block: () -> Unit
): Thread {
    val thread = object : Thread() {
        public override fun run() {
            block()
        }
    }
    if (isDaemon)
        thread.isDaemon = true
    if (priority > 0)
        thread.priority = priority
    if (name != null)
        thread.name = name
    if (contextClassLoader != null)
        thread.contextClassLoader = contextClassLoader
    if (start)
        thread.start()
    return thread
}

自定义类实现接口，一般在本类实现接口：

class Main : Runnable
{
	fun runBody()
	{
		Thread(this).start()
	}

	override fun run()
	{
	}

	companion object
	{
		@JvmStatic
		fun main(args: Array<String>)
		{
			val main = Main()
			main.runBody()
		}
	}
}

也可以而外定义，这些语法技巧，这里不再大篇幅介绍了，读者可自行实践。

实现Callable接口，重新call方法

 Callable接口严格说是Executor框架中的功能类，与Runnable功能类似，但有更加强大的功能。比如：

• Callable在任务接受后，提供一个返回值，Runnable则无此功能。
• Callable的call方法可以抛出异常，而Runnable的run方法不能抛出异常。
• Callable运行后可以拿到Future对象;Future对象表示异步操作的结果，提供了检查操作是否完成的方法。可以使用Future对象来监听目标线程调用call方法情况。但调用Future的get方法获取结果时，当前线程会被阻塞，直到目标线程call方法返回结果。

class Main
{
	fun runBody()
	{
		val myCallable = MyCallable()
		val service = Executors.newSingleThreadExecutor()
		val future = service.submit(myCallable)
		try {
			println(future.get())
		} catch (e: InterruptedException) {
			e.printStackTrace()
		} catch (e: ExecutionException) {
			e.printStackTrace()
		}
	}

	inner class MyCallable : Callable<String>
	{
		@Throws(Exception::class)
		override fun call(): String {
			return "你好，Frank Miles!"
		}
	}

	companion object
	{
		@JvmStatic
		fun main(args: Array<String>)
		{
			val main = Main()
			main.runBody()
		}
	}
}

 这里我们暂且不表newSingleThreadExecutor作用，只是宏观了解。

小结

 一般推荐实现runnbale接口，一个类应该在需要加强或修改时才会被继承，没有使用Thread其他重写方法的需求，就没有必要重写Thread方法。 ——《设计模式》

线程的状态

 java线程状态在运行的生命周期可能会处于一下6中状态之一。

• New 新创建状态。线程被创建，还没有调用start()，还有基础工作要做的状态。
• Runnable 可运行状态。一旦调用start()，就处于此状态。这个状态的线程，可能正在运行，也可能没有，这取决于操作系统给线程提供的运行时间。
• Blocked 阻塞状态。表示线程被锁阻塞，暂时不活动。
• Waiting 等待状态。暂不活动，不运行任何代码，直到线程调度器重新激活它。
• Time waiting 超时等待，区别于 Waiting，可以在指定时间自行返回。
• Terminated 终止状态。线程执行完毕，一是代码执行结束，二是异常没有捕获，强行终止。

 线程创建后（New ），start()调用开始，进入 Runnable 。之后操作如图示：

线程中断的理解

 一个线程在运行，可以调用stop()方法中断线程，但这个方法已经被废弃了。现在推荐使用interrupt()请求终止线程。
 当一个线程调用此方法时，线程中断标志位会设置为true。线程会不时检测这个中断标志位，以判断线程是否应该中断，要想知道线程是否被置位，可以调用Thread.currentThread().isInterrupted()，如下所示：

while (Thread.currentThread().isInterrupted) {
	// TODO
}

 也可以调用Thread.interrupted()对中断标志位进行复位。但若一个线程被阻塞，就无法检测中断状态。
 如果一个线程处于阻塞状态，那么线程在检测中断标志位的时候若为true，会在阻塞方法出抛出InterruptedException，并且在抛出前恢复中断标志位为false。
注意，interrupt()只是请求终止，是否终止，需要线程自行决定。

中断处理方式

如果你不知道如何处理，这里以sleep作为阻塞条件，介绍两种处理方式。
一种是，在catch语句中，重新设置中断标志位为true，让外界通过Thread.currentThread().isInterrupted()决定是终止线程还是继续：

try {
	Thread.sleep(100);
} catch (InterruptedException e) {
	Thread.currentThread().interrupt();
}

 更好的做法是直接抛出这个问题，不做处理，留给调用的人处理（嗯??）

@Throws(InterruptedException::class)
fun runBody() {
	Thread.sleep(100)
}

安全地终止线程

 调用interupted终止线程：

class Main
{
	private var counter = 0
	@Throws(InterruptedException::class)
	fun runBody()
	{
		val thread = Thread {
			while (!Thread.currentThread().isInterrupted)
			{
				counter++
				println(counter)
			}
			println("stop")
		}
		thread.start()
		// 留时间来感知结束
		TimeUnit.MICROSECONDS.sleep(100)
		thread.interrupt()
	}

	companion object
	{
		@Throws(InterruptedException::class)
		@JvmStatic
		fun main(args: Array<String>)
		{
			val main = Main()
			main.runBody()
		}
	}
}

 也可以使用 @Volatile boolean来自主控制是否需要终止线程。

class Main
{
	@Volatile
	private var running = true
	private var counter = 0
	@Throws(InterruptedException::class)
	fun runBody()
	{
		val thread = Thread {
			while (running)
			{
				counter++
				println(counter)
			}
			println("stop")
		}
		thread.start()
		TimeUnit.MICROSECONDS.sleep(100)
		cancel()
	}

	private fun cancel()
	{
		running = false
	}

	companion object
	{
		@Throws(InterruptedException::class)
		@JvmStatic
		fun main(args: Array<String>)
		{
			val main = Main()
			main.runBody()
		}
	}
}

@volatile 注解后面会说，这里可以理解为，“涉及多个线程访问时，修改变量会让所有线程能尽快感知”，尽快，也就是说，不用@volatile ，关系也不大，一样能终止，但终止时候，取决于这个线程什么时候去“检查这个变量”。

线程锁与同步

竞态条件

 两个或多个线程在对同一个变量进行读取和修改，这种行为可以称作竞态条件。
比如说买票问题：票数量固定，可以买票的地方很多，售票站就可称作线程，售票站需要查询和修改（购买）火车票，这样也是竞态条件。那么如何解决不同乘客买到同一座位的票的问题呢？解决办法是，当一个售票站需要购买票时，这个座位就被占用了（锁），其他售票站只能等待（线程阻塞）前一个售票站是否购买然后再做决定。

重入锁与条件对象

 重入锁ReentrantLock是java se 5.0引入，就是支持重进入的锁。它表示该锁能够支持一个线程对资源重复加锁。使用方法也简单：

public class Main
{
	public static void main(String[] args){
		Main main = new Main();
		main.runBody();
	}

	private final ReentrantLock mLock = new ReentrantLock();
	
	public void runBody() {
		Thread thread = new Thread(() -> {
			// 获得锁
			mLock.lock();
			// 解锁，如果有try-catch语句，应该在finally内加入以保证完整性。
			mLock.unlock();
		});

		thread.start();
	}
}

 发生异常，必须要释放锁，不然后面线程会永久阻塞▲

 锁的结构保证了访问或修改某值时，一次只能有一个线程，其他线程会被阻塞直到系统调度才运行。

 条件对象又称作条件变量，当一个线程获得锁后，却发现不满足条件，这时候就需要它。
 我见过很多教程，都是用转账来做例子，我认为这样还不够直观，使用转账例子，是为了更好说明多线程操作带来的死锁、金额总数变化的错误可能，但这里主要讲解条件对象，不会涉及上述知识，所以用类似申请权限的代码来做讲解分析，更容易理解，请先看代码：

class Main
{
	private val mLock = ReentrantLock()
	private lateinit var mCondition: Condition

	// 假设的条件
	private var needRunThread = true
	fun runBody()
	{
		// 得到条件对象
		mCondition = mLock.newCondition()
		runFirst()
		permission
	}

	private fun runFirst()
	{
		val thread = Thread {

			// 获得锁
			mLock.lock()
			try
			{
				// 真正工作中，发起授权可能会有些额外代码，这里只做输出。
				println("正在发起授权")
				while (needRunThread)
				{
					println("无授权，进入条件阻塞状态")
					mCondition!!.await()
				}
				println("已获得授权")
			} catch (pException: InterruptedException)
			{
				pException.printStackTrace()
			} finally
			{
				// 解锁
				mLock.unlock()
			}
		}
		thread.start()
	}

	// 让所有因此条件进入阻塞的线程进入 可 运行状态。
	private val permission: Unit
		get()
		{
			val thread = Thread {
				mLock.lock()
				needRunThread = false
				println("已允许给予授权")
				// 让所有因此条件进入阻塞的线程进入 可 运行状态。
				mCondition!!.signalAll()
				mLock.unlock()
			}
			thread.start()
		}

	companion object
	{
		@JvmStatic
		fun main(args: Array<String>)
		{
			val main = Main()
			main.runBody()
		}
	}
}

运行输出结果是：

正在发起授权
无授权，进入条件阻塞状态
已允许给予授权
已获得授权

 很明显，我们现在就能说明他们的执行过程：首先执行runFirst()，获得了锁，但条件并不满足，而且getPermission()也有同样的锁，上面也说了，同样的锁只能有一个线程，这就说明，runFirst()永远无法等待getPermission()的授权，因为getPermission()已经被锁阻塞了，这时候，就需要条件阻塞runFirst()线程（为什么不是结束runFirst()线程，等待授权后再运行？因为有的发起授权准备代码只能执行一次，而且也不容易在复杂场景实现）

 条件阻塞runFirst()线程方法很简单，调用await()就可以让runFirst进入阻塞状态，直到另一个线程调用signalAll()方法为止。

• signalAll() 重新激活因为同一条件而等待的所有线程
• signal() 重新激活因为同一条件而等待的随机的一条线程（有死锁的可能：激活的线程还不满足条件，也没激活其他线程）

  重新激活，不代表立即运行线程，而是只解除了等待线程的阻塞状态，以便这些线程通过竞争实现对象访问

同步方法块

 大多数情况下，使用ReentrantLock会显得过于臃肿，重复代码太多，所以在java 1.0开始，引入了嵌入到语言内部的同步和条件对象机制：java每一个类都有一个内部锁。
 比如说，若一个方法用@Synchronized 修饰，也就使用了方法所在的对象的锁来保护这个方法。比如：

@Synchronized
private fun body() {}

等价于

	private val mLock = ReentrantLock()

	private fun body()
	{
		mLock.lock()
		try
		{
			// todo
		} finally
		{
			mLock.unlock()
		}
	}

 也可以对代码块来实现锁：

synchronized (this /*建议 Object()*/) {
	// todo		
}

 这里需要指定锁的对象，即回答谁的锁这个问题。这里用的是本类的锁，这并不是Kotlin推荐写法****，推荐写法是使用Object。
另外，条件对象的方法，可以用Object自带的方法替代，替代规则如下：

Condition	Object方法
await()	wait()
signal() / signalAll()	notify() / notifyAll()

但是， kotlin的基类是Any，类似于java中的Object，但是没有提供wait()、notify()、notifyAll()方法。但是我们依然可以通过创建Object的实例，从而调用wait()、notify()、notifyAll()方法，但要注意的是，是 synchronized(lock) 而非 synchronized(this) 。

 现在，我们来替代上述代码，不使用ReentrantLock锁来实现：

class Main
{
	private val lock = Object()

	// 假设的条件
	private var needRunThread = true
	fun runBody()
	{
		runFirst()
		permission
	}

	private fun runFirst()
	{
		val thread = Thread {
			try
			{
				synchronized(lock) {

					// 真正工作中，发起授权可能会有些额外代码，这里只做输出。
					println("正在发起授权")
					while (needRunThread)
					{
						println("无授权，进入条件阻塞状态")
						lock.wait()
					}
					println("已获得授权")
				}
			} catch (pException: InterruptedException)
			{
				pException.printStackTrace()
			}
		}
		thread.start()
	}

	// 让所有因此条件进入阻塞的线程进入 可 运行状态。
	private val permission: Unit
		get()
		{
			val thread = Thread {
				synchronized(lock) {
					needRunThread = false
					println("已允许给予授权")
					// 让所有因此条件进入阻塞的线程进入 可 运行状态。
					lock.notifyAll()
				}
			}
			thread.start()
		}

	companion object
	{
		@JvmStatic
		fun main(args: Array<String>)
		{
			val main = Main()
			main.runBody()
		}
	}
}

小结

 同步代码是是非脆弱、难以纠错、维护性难的，通常只在简单线程使用。一般实现最好用java.util.concurrent包下的类。一般来说，只有在特别需要使用Lock/Condition结构时，才建议使用；只有在同步方法适合你的程序的时候，才建议使用同步代码块。

内存模型与并发特性

kotlin编译后和java相同，都是class类型，因此，底层也是一样的。

java内存模型

 Java堆内存用来存储对象实例，堆内存是被所有线程共享运行的内存区域，而局部变量、方法定义的参数则不会在线程共享。

 java内存定义了线程和主存之间的关系：线程间的共享变量储存在主存中，但线程都持有一个私有副本，当某线程副本被修改时，线程就会在合适的时机把数据提交到主存中，然后其他线程在合适时候从主存更新副本的值。

 需要注意的是，这只是一个抽象概念，并不真实存在，它是从缓存、写缓冲区、寄存区的角度来解释的。Java内存模型控制线程之间的通信，它决定一个线程对主存共享变量的写入何时对另一个线程可见。示意图可如下表示：

 线程A和线程B通信：A线程更新的变量数据提交给主存，然后B线程在合适时机读取主存变量并更新到副本中。

并发特性：原子性、可见性、重新排序和有序性

原子性

 对于基本数据的读取和赋值是原子操作，这些操作不能中断，要么执行，要么不执行。比如：

x = 3;

 特别的，以下操作就不是原子性：

y = x;
x++;

 y = x，执行了两个指令：1.读取x ，2. 把x的值赋值给y， 因此不具有原子性。
x++，自增操作不是原子性，因为它等价于 x = x +1，自然执行了三步：1. 读取 x, 2. 值x加1， 3. 把值赋值给x。所以也不具有原子性。

 java.util.concurrent.atomic包下很多类使用了机器级指令（不是锁）来保证给出的算法具有原子性，比如AtomicIntenger的方法，这些方法不多做介绍，请自查。值得注意的是，这些仅供开发并发工具的系统程序员使用，应用程序员不应该使用这些类。

可见性

 可见性，指的是线程之间的可见性，一个线程修改的状态对另一个线程是可见的，一个线程修改的结果，另一个线程可以立刻知晓。被volatile修饰的变量能保证立刻把值更新到主存中，所有其他线程可见，可读取新值。而未被volatile修饰的变量不一定会立刻更新到主存中去，自然其他线程读取的，可能是旧值。

重新排序

 编译器为或运行时环境为了优化程序而采取对指令进行重新排序执行的一种手段。分编译时环境产生的编译时排序和运行时环境产生的运行时排序。

有序性

 Java内存模型允许编译器和处理器对指令进行重新排序，重排序不会对单线程执行代码的正确性有任何影响，但会影响多线程并发执行的正确性。，除了volatile，也可以用上文提到的锁来保证有序性，也就是多线程操作指令由锁进行被动排序，实现先后访问，而不是交叉访问和修改值。

@Volatile用法

@Volatile修饰的变量会在编译后自动加上volatile语句，这和java是一样的，只是写法区别罢了。

 @Volatile设计目的是在解决简单的读写一两个实例而提供同步访问的免锁机制。一个修饰了@Volatile的域，那么编译器和虚拟机就知道此域可能被另一个线程并发更新。

 共享变量被@Volatile修饰后，就会有两层含义。一、线程修改变量后，其他线程可立即感知。二、禁止使用指令进行重排序。

不保证原子性： @Volatile没有说所有牵涉到该变量的操作都具备原子性：比如自增就不属于。事实上，也确实没有原子性，只是保证数据修改时，其他线程可立即感知。

保证有序性： 因为@Volatile能禁止指令重排序。可以解释为，在 @Volatile变量之前的语句，不会 @Volatile之后执行。

@Volatile可能优于 synchronized ，但优于不满足原子性，所以不能替代synchronized 。
 通常说，使用 @Volatile 必须具备以下条件：

• 对变量的写操作不会依赖当前值。就是不能是自增、自减之类赋值依赖原有变量操作。

• 该变量没有包含在具有其他变量的不变式中。也就是说，多个被@Volatile修饰的变量若一定满足某些不变公式（比如@Volatile a 一定 大于 @Volatile b）,由于多个线程的操作，这个不变式有被打破的风险。
  使用@Volatile一般有两种，其他具体用法可自行查阅资料。

1. 状态标志，这个很常见，我们也用到过：

class Main
{
	@Volatile
	private var running = true
	private var counter = 0
	
	@Throws(InterruptedException::class)
	fun runBody()
	{
		val thread = Thread {
			while (running)
			{
				counter++
				println(counter)
			}
			println("stop")
		}
		thread.start()
		TimeUnit.MICROSECONDS.sleep(100)
		cancel()
	}

	private fun cancel()
	{
		running = false
	}

	companion object
	{
		@Throws(InterruptedException::class)
		@JvmStatic
		fun main(args: Array<String>)
		{
			val main = Main()
			main.runBody()
		}
	}
}

2. DCL （双重检查模式）
   双重检查模式，一般用在设计模式的单例模式。

class Main private constructor()
{
	companion object
	{
		@Volatile
		private var instance: Main? = null

		// 这里牺牲一点性能保证正确性
		fun getInstance(): Main
		{
			// 防止冗余同步
			if (instance == null)
			{
				synchronized(Main::class.java) {
					// 防止冗余实例化
					if (instance == null)
					{
						instance = frms.Main()
					}
				}
			}
			return instance!!
		}
	}
}

小结

 @Volatile 是一种简单而十分脆弱的同步机制，简单情况下确实优于锁的性能。在严格遵守使用规则确实能简化代码，但是因为@Volatile出错的代码比synchronized 更难发现和维护，也更容易出错，请酌情使用。