首页 > 代码库 > 谈谈多线程开发中的线程和任务的理念

谈谈多线程开发中的线程和任务的理念

前段时间写了一个iOS端的数据统计SDK,数据统计有些复杂的计算和数据上报操作。由于有些操作比較耗时。所以不得不在后台线程进行操作,由此引发了我对多线程的思考,在iOS开发中,一般非常难再见到直接使用NSThread进行多线程编程的了。由于苹果提供了另外几种多线程开发的解决方式。而这些解决方式面向的不再是线程,而是面向的是任务,以下就来以iOS和Android为例简单谈谈的线程和任务的相关概念。

线程:

我们在学习基础的编程语言的时候,肯定听说过线程的概念,线程是操作系统调度的最小单位,共享进程资源。可能对于非常多人来说多线程编程并非特别在意。可是当你真的有需求的时候要不太好使用。比如我有一个需求:如今有一系列的操作都要在其它线程中完毕,而且任务的运行的先后顺序就是任务加入的顺序,而且让不同 的任务按顺序依次运行。那么这时候可能你首先会想开多个线程,然后你就会想如何控制各个线程运行的顺序呢?显然这样的顺序是非常难控制的。由于你非常难控制哪个线程先运行,哪个线程后运行。

很熟悉java代码线程池的同学肯定会想到用java中的线程池ThreadPoolExecutor,然后让其最大的线程数设置为1,这样就能够实现上述需求,不错这样做的确能够实现上述需求,只是ThreadPoolExecutor的内部是如何做到的呢?ThreadPoolExecutor的实现原理是如何的呢?难道ThreadPoolExecutor脱离了java线程的概念 有特殊的权限?

假设熟悉OC的同学可能会立刻想起一种并发编程技术:GCD这样的技术能够设置一个串行队列,然后增加异步任务就能够实现,确实也是能够实现的。

不同语言中的不同的技术确实都能够实现此类需求。

可这些技术的实现是否脱离了操作系统本身的多线程机制,拥有特殊权限。特殊API?答案是否定的,以下就来说说任务的概念。

任务:

任务和多线程没有关系的,一个任务可能就是若干操作的集合。假设我们转变思想,把面向线程的编程改成面向任务的编程,那么并发编程是不是就拥有更好的可控制性,包含顺序。线程数量等等。任务的核心概念就是把任务放到任务队列中。然后开启指定个数的线程不停的从任务队列中取得对应的任务在本线程中运行,因为任务是放在任务队列中的,因为队列的特性,能够保证任务的运行是依照放入队列中的顺序运行的。

而且能够指定最大开多少个线程,这样就能够保证性能的消耗不是无限制的添加。事实上java中的ThreadPoolExecutor就是这样实现的,放入当中的每一个Runnable对象,就是一个一个的任务。然后ThreadPoolExecutor开启指定个数的线程依次从任务队列中取出任务去运行。我想oc的GCD应该也是类似实现的。把面向线程的编程编程面向任务的编程是并发编程的一大进步,而且具有更高的可控性。

讲到这里大家是不是对线程和任务的概念有一些理解了,如有不妥欢迎拍砖。


谈谈多线程开发中的线程和任务的理念