jmeter-线程组

路径：选中测试计划右键-添加-线程-线程组

1 线程数：虚拟用户数。一个虚拟用户占用一个进程或线程。设置多少虚拟用户数在这里也就是设置多少个线程数。

2 Ramp-Up Period(in seconds)准备时长：设置的虚拟用户数需要多长时间全部启动。如果线程数为10，准备时长为2，那么需要2秒钟启动10个线程，也就2秒内启动10，每秒启动的数量随机。

3 循环次数：每个线程发送请求的次数。如果线程数为10，循环次数为100，那么每个线程发送100次请求。总请求数为10100=1000 。如果勾选了“永远”，那么所有线程会一直发送请求，一到选择停止运行脚本。

4 调度器：设置线程组启动的开始时间和结束时间(配置调度器时，需要勾选循环次数为永远)

与Stepping Thread Group线程组有些类似，不过这个是多个线程组设置的结合。执行的时候，每个线程组是同时按照自己的规则开始执行的，每一时刻，得到的结果都是两个线程组的叠加（插件自行寻找）

This Group will start 10 threads：这次的测试总共会起10个线程。

First , wait for 0 seconds：等待0s后开始起线程，也就是不等待直接起线程。

Then start 0 threads；从0个线程开始持续增加。

Next，add 2 threads every 3 seconds：每增加2个线程后会运行3s，再起余下的2个线程，再运行3s，以此类推。

Using ramp-up 6seconds：前面每起2个线程的时候花6s，与上面结合起来即6s内起2个线程，运行3s，然后再6s内再起2个线程，再运行3s，以此类推。

Then hold load for 30 seconds ：全部的线程起来后，运行30s 后开始停止。

Finally , stop 2 threads every 1 seconds：最后停止线程，2个线程停一次，等1s再停2个线程。

xxl-job 的 admin 服务是 xxl-job 的调度中心，负责管理和调度注册的 job，关于 xxl-job 的使用，可以阅读 “参考阅读” 中的《XXL-JOB分布式调度框架全面详解》，这里主要是介绍 admin 中的源码。

admin 服务除了管理页面上的一些接口外，还有一些核心功能，比如：

1、根据 job 的配置，自动调度 job；

2、接收 executor 实例的请求，实现注册和下线；

3、监视失败的 job，进行重试；

4、结束一些异常的 job；

5、清理和统计日志；

这些功能都是在 admin 服务启动后，在后台自动运行的，下面将详细介绍 admin 服务这些功能的实现。

XxlJobAdminConfig 是 admin 服务的配置类，在 admin 服务启动时，它除了配置 admin 服务的一些参数外，还会启动 admin 服务的所有后台线程。

该类的属性主要分为5类：

1、配置文件中的参数，比如 accessToken；

2、DAO 层各个数据表的 mapper；

3、Spring 容器中的一些 Bean，比如 JobAlarmer、DataSource 等；

4、私有变量 XxlJobScheduler 对象；

5、私有静态变量 adminConfig，指向实例自身。

该类有两个重要方法，分别实现自接口 InitializingBean、DisposableBean，作用如下：

这两个方法分别调用了 XxlJobScheduler 对象的 init 、 destroy 方法，源码如下：

XxlJobAdminConfig 作为 admin 服务的配置类，作用就是在 Spring 容器启动时，调用 XxlJobScheduler 的初始化方法，来初始化和启动 admin 服务的功能。

XxlJobScheduler 的作用就是调用各个辅助类（xxxHelper）来启动和结束不同的线程和功能，初始化方法 init 的代码如下：

下面我们主要介绍 init 中各个类及其作用，最后再简单一下介绍 destroy 的作用。

当 admin 服务向 executor 实例发出一个调度请求来执行 job 时，会调用 XxlJobTriggertrigger() 方法把要传输的参数（比如 job_id、jobHandler、job_log_id、阻塞策略等，包装成 TriggerParam 对象）传给 ExecutorBiz 对象来执行一次调度。

xxl-job 对调度过程做了两个优化：

JobTriggerPoolHelper 在 toStart 方法中初始化了它的两个线程池属性，代码如下：

每次有调度请求时，就会在这两个线程池中创建线程，创建线程的逻辑在 addTrigger 方法中。

不同 job 存在执行时长的差异，为了避免不同耗时 job 之间相互阻塞，xxl-job 根据 job 的响应时间，对 job 进行了区分，主要体现在：

如果快 job 与调用频繁的慢 job 在同一个线程池中创建线程，慢 job 会占用大量的线程，导致快 job 线程不能及时运行，降低了线程池和线程的利用率。xxl-job 通过快慢隔离，避免了这个问题。

不能，因为慢 job 还是会占用大量线程，抢占了快 job 的线程资源；增加线程池中的线程数不但没有提升利用率，还会导致大量线程看空闲，利用率反而降低了。最好的方法还是用两个线程池把两者隔离，可以合理地使用各自线程池的资源。

为了记录慢 job 的超时次数，代码中使用一个 map（变量 jobTimeoutCountMap ）来记录一分钟内 job 超时次数，key 值是 job_id，value 是超时次数。在调用 XxlJobTriggertrigger() 方法之前，会先判断 map 中，该 job_id 的超时次数是否大于 10，如果大于10，就是使用 slowTriggerPool，代码如下：

调用 XxlJobTriggertrigger() 方法后，根据两个值来更新 jobTimeoutCountMap 的值：

和上面的代码相结合，一个 job 在一分钟内有10次调用超过 500 毫秒，就认为该 job 是一个 频繁调度且耗时的 job。

代码如下：

在该类中，属性变量 minTim 和 jobTimeoutCountMap 都使用 volatile 来修饰，保证了并发调用 addTrigger 时数据的一致性和可见性。

admin 服务发起 job 调度请求时，是在静态方法 public static void trigger() 中调用静态变量 private static JobTriggerPoolHelper helper 的 addTrigger 方法来发起请求的。minTim 和 jobTimeoutCountMap 虽然不是 static 修饰的，但可以看做是全局唯一的（因为持有它们的对象是全局唯一的），因此这两个参数维护的是 admin 服务全局的调度时间和超时次数，为了避免记录的数据量过大，需要每分钟清空一次数据的 *** 作。

admin 服务提供了接口给 executor 来注册和下线，另外，当 executor 长时间（90秒）没有发心跳时，要把 executor 自动下线。前一个功能通过暴露一个接口来接收请求，后一个功能需要开启一个线程，定时更新过期 executor 的状态。

xxl-job 为了提升 admin 服务的性能，在前一个功能的接口接收到 executor 的请求时，不是同步执行，而是在线程池中开启一个线程，异步执行 executor 的注册和下线请求。

JobRegistryHelper 类就负责管理这个线程池和定时线程的。

线程池的定义和初始化代码如下：

executor 实例在发起注册和下线请求时，会调用 AdminBizImpl 类的对应方法，该类的方法如下：

可以看到，AdminBizImpl 类的两个方法都是调用了 JobRegistryHelper 方法来实现，其中 JobRegistryHelperregistry 方法代码如下（registryRemove 代码与之相似）：

这两个方法是通过在线程池 registryOrRemoveThreadPool 中创建线程来异步执行请求，然后把数据更新或新建到数据表 xxl_job_registry 中。

当 executor 注册到 admin 服务后（数据入库到 xxl_job_registry 表），是不会在页面上显示的，需要要用户手动添加 job_group 数据（添加到 xxl_job_group 表），admin 服务会自动把用户添加的 job_group 数据与 xxl_job_registry 数据关联。这就需要 admin 定时从 xxl_job_group 表读取数据，关联 xxl_job_registry 表和 xxl_job_group 表的数据。

这个功能是与 “executor 自动下线” 功能在同一个线程中实现，该线程的主要逻辑是：

相关代码如下：

从这里可以看出，如果是对外接口（接收请求等）的功能，使用线程池和异步线程来实现；如果是一些自动任务，则是通过一个线程来定时执行。

如果一个 Job 调度后，没有响应返回，需要定时重试。作为一种“自动执行”的任务，很显然可以像前面 JobRegistryHelper 一样，使用一个线程定时重试。

在这个类中，定义了一个监视线程，以每10 秒一次的频率运行，对失败的 job 进行重试。如果 job 剩余的重试次数大于0，就会 job 进行重试，并把发送告警信息。线程的定义如下：

在这个线程中，它利用 “数据库执行 UPDATE 语句时会加上互斥锁” 的特性，使用了 “基于数据库的分布式锁”，代码如下所示：

在这个语句中，会把 jobLog 的状态设置为 -1，这是一个无效状态值，当其他线程通过有效状态值来搜索失败记录时，会略过该记录，这样该记录就不会被其他线程重试，达到的分布式锁的功能（这个锁是一个行锁）。或者说，-1状态类似于 java 中的对象头的锁标志位，表明该记录已经被加锁了，其他线程会“忽略”该记录。

在 try 代码块中加锁和解锁，如果加锁后重试时抛出异常，会导致该记录永远无法解锁。所以，应该在 finnally 块中执行解锁 *** 作，或者使用 redis 给锁加一个过期时间来实现分布式锁。

从失败的日志中取出 jobId，查询出对应的 jobInfo 数据，如果日志中的剩余重试次数大于 0，就执行重试。代码如下：

调度任务使用的就是前面介绍的 JobTriggerPoolHelpertrigger 方法，最后更新 jobLog 的 alarm_status 值，有两个作用：

这个类与 JobRegistryHelper 类似，都有一个线程池、一个线程，通过前面 JobRegistryHelper 的学习，可以大胆猜测：

实际上，该类中线程池和线程的作用就是用来 “完成” 一个 job。

当 executor 接收到 admin 的调度请求后，会异步执行 job，并立刻返回一个回调。

admin 接受到回调后，和前面的 “注册、下线” 一样，在线程池中创建线程来处理回调，主要是更新 job 和日志。

当有回调请求时， public callback 方法（该方法被 AdminBizImpl 调用）会在线程池中创建一个线程，遍历回调请求的参数列表，依次处理回调参数，代码如下：

从代码可以看出，最后调用 XxlJobCompleterupdateHandleInfoAndFinish 方法完成回调逻辑。

如果一个 job 较长时间前被调度，但是一直处于 “运行中” 且它所属的 executor 已经超过 90 秒没有心跳了，那么可以认为该 job 已经丢失了，需要把该 job 结束掉。这个就是线程 monitorThread 的主要功能。

monitorThread 会以 60秒 一次的频率，从 xxl_job_log 表中找出 10分钟前调度、仍处于”运行中“状态、executor 已经下线 的 job，然后调用 XxlJobCompleterupdateHandleInfoAndFinish 来更新 handler 的信息和结束 job，代码如下：

从代码可以看出，上面的两个功能最后都调用了 XxlJobCompleterupdateHandleInfoAndFinish 方法，关于该方法的介绍，可以看后面 XxlJobCompleter 部分的介绍，这里不详细展开。

如果去看 XxlJobTriggertriger 方法，会发现每次调度 job 时，都会先新增一个 jobLog 记录，这也是为什么 JobFailMonitorHelper 中的线程在重试时，先查询 jobLog 的原因。

JobLog 作为 job 的调度记录，还可以用来统计一段时间内 job 的调度次数、成功数等；另外，会清理超出有效期（配置的参数 logretentiondays ）的日志，避免日志数据过大。很显然，这又是一个 ”自动任务“，可以使用一个线程定时完成。

该类持有一个线程变量，线程以 每分钟一次的频率，执行两个 *** 作：

在线程 run 方法的前半部分，线程会统计 3 天内，每天的调度次数、运行次数、成功运行数、失败次数；然后更新或新增 xxl_job_log_report 表的数据。

在线程 run 方法的后半部分，线程按天对日志进行清理，如果当前时间与上次清理的时间相隔超过一天，就会清理日志记录，代码如下：

如果不使用参数 lastCleanLogTime 来记录上次清理的时间，只是清理一天前创建的数据记录。那么该线程每分钟执行一次时，都会删除前天当前时刻的数据，导致前一年的数不完整。

使用参数 lastCleanLogTime 来记录上次清理的时间，并且与当前时间相差超过一天时才清理，能保证前一天的日志是完整的。

不明白为什么清理日志时，不是一次性删除全部的过期日志，而是每次删除 1000条。按理说，这些旧的日志数据应该已经不在 buffer pool 中了，trigger_time 字段又是普通索引，那么 DELETE *** 作会先更新到 change buffer 中，之后再合并。现在先查询再删除，相当于多了一次 IO 且没有使用到 change buffer。

admin 服务是用来管理和调度 job 的，用户也可以在它的管理后台新建一个 job，配置 CRON 和 JobHandler，然后 admin 服务就会按照配置的参数来调度 job。很显然，这种“自动化工作”也是由线程定时执行的。

1、如果使用线程调度 Job，存在的第一个问题是：如果某个 Job 在调度时比较耗时，就可能阻塞后续的 Job，导致后续 job 的执行有延迟，怎么解决这个问题？

在前面 JobTriggerPoolHelper 我们已经知道，admin 在调度 job 时是 ”使用线程池、线程“ 异步执行调度任务，避免了主线程的阻塞。

2、使用线程定时调度 job，存在的第二个问题是：怎么保证 job 在指定的时间执行，而不会出现大量延迟？

admin 使用 ”预读“ 的方式，提前读取在未来一段时间内要执行的 job，提前取到内存中，并使用 “时间轮算法” 按时间分组 job，把未来要执行的 job 下一个时间段执行。

3、还隐藏第三个问题：admin 服务是可以多实例部署的，在这种情况下该怎么避免一个 job 被多个实例重复调度？

admin 把一张数据表作为 “分布式锁” 来保证只有一个 admin 实例能执行 job 调度，又通过随机 sleep 线程一段时间，来降低线程之间的竞争。

下面我们就通过代码来了解 xxl-job 是怎么解决上述问题的。

在该类中，定义了一个调度线程，用来调度要执行的 job 和已经过期一段时间的 job，定义代码如下：

该线程会预读出 “下次执行时间 <= now + 5000 毫秒内” 的部分 job，根据它们下一次执行时间划分成三段，执行三种不同的逻辑。

1、下次执行时间在 (- , now - 5000) 范围内

说明过期时间已经大于 5000 毫秒，这时如果过期策略要求调度，就调度一次。代码如下：

2、下次执行时间在 [now - 5000, now) 范围内

说明过期时间小于5000毫秒，只能算是延迟不能算是过期，直接调度一次，代码如下：

如果 job 的下一次执行时间在 5000 毫秒以内，为了省下下次预读的 IO 耗时，这里会记录下 job id，等待后面的调度。

3、下次执行时间在 [now, now + 5000) 范围内

说明还没到执行时间，先记录下 job id， 等待后面的调度 ，代码如下：

上面的3个步骤结束后，会更新 jobInfo 的 trigger_last_time、trigger_next_time、trigger_status 字段：

可以看到，通过预读，一方面会把过期一小段时间的 job 执行一遍，另一方面会把未来一小段时间内要执行的 job 取出，保存进一个 map 对象 ringData 中，等待另一个线程调度。这样就避免了某些 job 到了时间还没执行。

因为 admin 是可以多实例部署的，所以在调度 job 时，需要考虑怎么避免 job 被多次调度。

xxl-job 在前面 JobFailMonitorHelper 中遍历失败的 job 时，会对每个 job 设置一个无效的状态作为 ”分布式行锁“，如果设置失败就跳过。而在这里，如果还使用该方法，有可能出现，一个 job 被设置为无效状态后，线程就崩溃了，导致该 job 永远无法被调度。因此，要尽量避免对 job 状态的修改。

在这里，admin 服务使用一张表 xxl_job_lock 作为分布式锁，每个 admin 实例都要先尝试获取该表的锁，获取成功才能继续执行；同时，为了降低不同实例之间的竞争，会在线程开始执勤随机 sleep 一段时间。

如何获取分布式锁？

在线程中会开启一个事务，设置为手动提交，然后对表 xxl_job_lock 执行 FOR UPDATE 查询。如果该线程执行语句成功，其他实例的线程就会排队等待该表的锁，实现了分布式锁功能。代码如下：

怎么降低锁的竞争？

为了降低锁竞争，在线程开始前会先 sleep 4000 5000 毫秒的随机值（不能大于 5000 毫秒，5000 毫秒是预读的时间范围）；在线程结束当前循环时，会根据耗时和是否有预读数据，选择不同的 sleep 策略：

代码如下：

在前面的线程中，对即将要开始的 job，不是立刻调度，而是按照执行的时刻（秒），把 job id 保存进一个 map 中，然后由 ringThread 线程按时刻进行调度，这只典型的“时间轮算法”。代码如下：

每次轮询调度时，只取出当前时刻（秒）、前一秒内的 job，不会去调度与现在相隔太久的 job。

在执行轮询调度前，有一个时间在 0 1000 毫秒范围内的 sleep。如果没有这个 sleep，该线程会一直执行，而 ringData 中当前时刻（秒）的数据可能已经为空，会导致大量无效的 *** 作；增加了这个 sleep 之后，可以避免这种无效的 *** 作。之所以 sleep 时间在 1000 毫秒以内，是因为调度时刻最小精确到秒，一秒的 sleep 可以避免 job 的延迟。

因为在前面的 scheduleThread 线程中，最后一个 *** 作是把 job 的 next_trigger_time 值更新为大于 now + 5000 毫秒，其他 admin 实例 scheduleThread 线程的查询条件是：next_trigger_time < now + 5000，不会查询出这里调度的 job，所以不需要加分布式锁。

至此，XxlJobScheduler-init 方法的作用我们介绍完毕，下面我们简单介绍一下 XxlJobScheduler-destroy 方法

destroy 方法很简单，就是销毁前面初始化的线程池和线程，它销毁的顺序与前面启动的顺序相反。

代码如下：

因为各个 toStop 方法都很相似，所以我们只介绍 JobScheduleHelper 的 toStop 方法。

该方法的步骤如下：

1、设置停止标志位为 true；

2、sleep 一段时间，让出 CPU 时间片给线程执行任务；

3、如果线程不是终止状态（线程正在 sleep），中断它；

4、线程执行 join 方法，直到线程结束，执行最后一次。

代码如下：

至此，JobScheduleHelper 的主要功能就介绍完了，可以看出， admin 服务在启动时，启动了多个线程池和线程，异步执行任务和异步响应 executor 的请求。

下面，我们介绍前面涉及到的 XxlJobTrigger 和 XxlJobCompleter。

XxlJobTrigger 是调度 job 时的封装类，它主要工作就是接受传入的 jobId、调度参数等，查询对应的 jobGroup、jobInfo，然后调用 ExecutorBiz 对象来执行调度（run 方法）。

该类中三个核心方法及其调用关系如下： trigger -> processTrigger -> runExecutor ，

该方法的功能比较简单，就是根据传入的参数查询 jobGroup 和 jobInfo 对象，设置相关的字段值，然后调用 processTrigger 方法。

该方法的主要工作分为以下几步：

1、保存一条调度日志；

2、从 jobInfo、jobGroup 中取出字段值，构造 TriggerParam 对象；

3、根据 jobInfo 的路由策略，从 jobGroup 中取出要调度的 executor 地址；

4、调用 runExecutor 方法执行调度；

5、保存调度参数、设置调度信息、更新日志。

这里不会修改 jobInfo、jobGroup 对象的字段值，只取出字段值来使用，对这两个对象字段的修改，是在前一步 trigger 方法中进行的。

该方法会执行调度，并返回调度结果，它的核心代码如下：

这里使用 XxlJobScheduler 类取出 ExecutorBiz 对象，以 “懒加载” 的方式给每个 address 创建一个 ExecutorBiz 对象，代码如下：

可以看出，该类中的三个方法其实可以归类为：pre -> execute -> post，在执行前、执行时、执行后做一些前置和收尾工作。

该类在前面 JobCompleteHelper 中被使用，最终 job 的完成就是在该类中执行的，该类有两个主要方法：

下面主要介绍 finishJob 方法。

finishJob 的主要功能是：如果当前任务执行成功了，就调度它的所有子任务，最后把子任务的调度消息添加到当前 job 的日志中。代码如下：

需要注意的是：

1、这里依赖于 JobTriggerPoolHelper 来调度 job，所以在 JobCompleteHelper 的监视线程开始时，有一个 50 秒的等待，就是等待 JobTriggerPoolHelper 启动完成；

2、在 finishJob 方法中，调度子任务的时候，默认子任务的调度结果是成功，注意，这里是指 “调度” 这个行为是成功的，而不是指子任务执行是成功的。

1、XxlJobAdminConfig 作为 admin 服务的启动入口，要尽可能保持简洁，作用类似于一个仓库，来管理和持有所有的类和对象，并不会去启动具体的线程，它只需要“按下启动器的按钮”就可以了；

2、XxlJobScheduler 是 admin 服务的启动器类，它会调用各个辅助类（xxxHelper）来启动对应的线程；

3、对外的接口，比如调度 job、接收注册或下线等，都是使用线程池 + 线程 的异步方式实现，避免 job 对主线程的阻塞；

4、对“自动任务“类的功能，都是使用线程定时执行；

XXL-JOB分布式调度框架全面详解： >

/// <summary>

/// 简单的 线程执行的 方法

///

/// 这个方法是 静态的

/// </summary>

public static void ThreadFunc()

{

// 线程停止运行的标志位

Boolean done = false;

// 计数器

int count = 0;

while (!done)

{

// 休眠1秒

ThreadSleep(1000);

// 计数器递增

count++;

// 输出

ConsoleWriteLine("[静态]执行次数：{0}", count);

}

}

/// <summary>

/// 启动线程的代码

/// </summary>

public static void StartThread()

{

ThreadStart ts = new ThreadStart(ThreadFunc);

Thread t = new Thread(ts);

// 启动

tStart();

}

全部的例子代码看下面的帖子

>

使用Python中的线程模块，能够同时运行程序的不同部分，并简化设计。如果你已经入门Python，并且想用线程来提升程序运行速度的话，希望这篇教程会对你有所帮助。

线程与进程

什么是进程

进程是系统进行资源分配和调度的一个独立单位 进程是具有一定独立功能的程序关于某个数据集合上的一次运行活动,进程是系统进行资源分配和调度的一个独立单位。每个进程都有自己的独立内存空间，不同进程通过进程间通信来通信。由于进程比较重量，占据独立的内存，所以上下文进程间的切换开销（栈、寄存器、虚拟内存、文件句柄等）比较大，但相对比较稳定安全。

什么是线程

CPU调度和分派的基本单位 线程是进程的一个实体，是CPU调度和分派的基本单位,它是比进程更小的能独立运行的基本单位线程自己基本上不拥有系统资源,只拥有一点在运行中必不可少的资源(如程序计数器,一组寄存器和栈),但是它可与同属一个进程的其他的线程共享进程所拥有的全部资源。线程间通信主要通过共享内存，上下文切换很快，资源开销较少，但相比进程不够稳定容易丢失数据。

进程与线程的关系图

线程与进程的区别：

进程

现实生活中，有很多的场景中的事情是同时进行的，比如开车的时候 手和脚共同来驾驶 汽车 ，比如唱歌跳舞也是同时进行的，再比如边吃饭边打电话；试想如果我们吃饭的时候有一个领导来电，我们肯定是立刻就接听了。但是如果你吃完饭再接听或者回电话，很可能会被开除。

注意：

多任务的概念

什么叫 多任务 呢？简单地说，就是 *** 作系统可以同时运行多个任务。打个比方，你一边在用浏览器上网，一边在听MP3，一边在用Word赶作业，这就是多任务，至少同时有3个任务正在运行。还有很多任务悄悄地在后台同时运行着，只是桌面上没有显示而已。

现在，多核CPU已经非常普及了，但是，即使过去的单核CPU，也可以执行多任务。由于CPU执行代码都是顺序执行的，那么，单核CPU是怎么执行多任务的呢？

答案就是 *** 作系统轮流让各个任务交替执行，任务1执行001秒，切换到任务2，任务2执行001秒，再切换到任务3，执行001秒，这样反复执行下去。表面上看，每个任务都是交替执行的，但是，由于CPU的执行速度实在是太快了，我们感觉就像所有任务都在同时执行一样。

真正的并行执行多任务只能在多核CPU上实现，但是，由于任务数量远远多于CPU的核心数量，所以， *** 作系统也会自动把很多任务轮流调度到每个核心上执行。 其实就是CPU执行速度太快啦！以至于我们感受不到在轮流调度。

并行与并发

并行（Parallelism）

并行：指两个或两个以上事件（或线程）在同一时刻发生，是真正意义上的不同事件或线程在同一时刻，在不同CPU资源呢上（多核），同时执行。

特点

并发（Concurrency）

指一个物理CPU(也可以多个物理CPU) 在若干道程序（或线程）之间多路复用，并发性是对有限物理资源强制行使多用户共享以提高效率。

特点

multiprocessProcess模块

process模块是一个创建进程的模块，借助这个模块，就可以完成进程的创建。

语法：Process([group [, target [, name [, args [, kwargs]]]]])

由该类实例化得到的对象，表示一个子进程中的任务（尚未启动）。

注意：1 必须使用关键字方式来指定参数；2 args指定的为传给target函数的位置参数，是一个元祖形式，必须有逗号。

参数介绍：

group：参数未使用，默认值为None。

target：表示调用对象，即子进程要执行的任务。

args：表示调用的位置参数元祖。

kwargs：表示调用对象的字典。如kwargs = {'name':Jack, 'age':18}。

name：子进程名称。

代码：

除了上面这些开启进程的方法之外，还有一种以继承Process的方式开启进程的方式：

通过上面的研究，我们千方百计实现了程序的异步，让多个任务可以同时在几个进程中并发处理，他们之间的运行没有顺序，一旦开启也不受我们控制。尽管并发编程让我们能更加充分的利用IO资源，但是也给我们带来了新的问题。

当多个进程使用同一份数据资源的时候，就会引发数据安全或顺序混乱问题，我们可以考虑加锁，我们以模拟抢票为例，来看看数据安全的重要性。

加锁可以保证多个进程修改同一块数据时，同一时间只能有一个任务可以进行修改，即串行的修改。加锁牺牲了速度，但是却保证了数据的安全。

因此我们最好找寻一种解决方案能够兼顾：1、效率高（多个进程共享一块内存的数据）2、帮我们处理好锁问题。

mutiprocessing模块为我们提供的基于消息的IPC通信机制：队列和管道。队列和管道都是将数据存放于内存中 队列又是基于（管道+锁）实现的，可以让我们从复杂的锁问题中解脱出来， 我们应该尽量避免使用共享数据，尽可能使用消息传递和队列，避免处理复杂的同步和锁问题，而且在进程数目增多时，往往可以获得更好的可获展性（ 后续扩展该内容 ）。

线程

Python的threading模块

Python 供了几个用于多线程编程的模块，包括 thread, threading 和 Queue 等。thread 和 threading 模块允许程序员创建和管理线程。thread 模块 供了基本的线程和锁的支持，而 threading 供了更高级别，功能更强的线程管理的功能。Queue 模块允许用户创建一个可以用于多个线程之间 共享数据的队列数据结构。

python创建和执行线程

创建线程代码

1 创建方法一:

2 创建方法二:

进程和线程都是实现多任务的一种方式，例如：在同一台计算机上能同时运行多个QQ（进程),一个QQ可以打开多个聊天窗口（线程）。资源共享：进程不能共享资源，而线程共享所在进程的地址空间和其他资源，同时，线程有自己的栈和栈指针。所以在一个进程内的所有线程共享全局变量，但多线程对全局变量的更改会导致变量值得混乱。

代码演示:

得到的结果是：

首先需要明确的一点是GIL并不是Python的特性，它是在实现Python解析器(CPython)时所引入的一个概念。就好比C++是一套语言（语法）标准，但是可以用不同的编译器来编译成可执行代码。同样一段代码可以通过CPython，PyPy，Psyco等不同的Python执行环境来执行（其中的JPython就没有GIL）。

那么CPython实现中的GIL又是什么呢？GIL全称Global Interpreter Lock为了避免误导，我们还是来看一下官方给出的解释：

主要意思为:

因此，解释器实际上被一个全局解释器锁保护着，它确保任何时候都只有一个Python线程执行。在多线程环境中，Python 虚拟机按以下方式执行:

由于GIL的存在，Python的多线程不能称之为严格的多线程。因为 多线程下每个线程在执行的过程中都需要先获取GIL，保证同一时刻只有一个线程在运行。

由于GIL的存在，即使是多线程，事实上同一时刻只能保证一个线程在运行， 既然这样多线程的运行效率不就和单线程一样了吗，那为什么还要使用多线程呢？

由于以前的电脑基本都是单核CPU，多线程和单线程几乎看不出差别，可是由于计算机的迅速发展，现在的电脑几乎都是多核CPU了，最少也是两个核心数的，这时差别就出来了：通过之前的案例我们已经知道，即使在多核CPU中，多线程同一时刻也只有一个线程在运行，这样不仅不能利用多核CPU的优势，反而由于每个线程在多个CPU上是交替执行的，导致在不同CPU上切换时造成资源的浪费，反而会更慢。即原因是一个进程只存在一把gil锁，当在执行多个线程时，内部会争抢gil锁，这会造成当某一个线程没有抢到锁的时候会让cpu等待，进而不能合理利用多核cpu资源。

但是在使用多线程抓取网页内容时，遇到IO阻塞时，正在执行的线程会暂时释放GIL锁，这时其它线程会利用这个空隙时间，执行自己的代码，因此多线程抓取比单线程抓取性能要好，所以我们还是要使用多线程的。

GIL对多线程Python程序的影响

程序的性能受到计算密集型(CPU)的程序限制和I/O密集型的程序限制影响,那什么是计算密集型和I/O密集型程序呢

计算密集型：要进行大量的数值计算，例如进行上亿的数字计算、计算圆周率、对视频进行高清解码等等。这种计算密集型任务虽然也可以用多任务完成，但是花费的主要时间在任务切换的时间，此时CPU执行任务的效率比较低。

IO密集型：涉及到网络请求(timesleep())、磁盘IO的任务都是IO密集型任务，这类任务的特点是CPU消耗很少，任务的大部分时间都在等待IO *** 作完成（因为IO的速度远远低于CPU和内存的速度）。对于IO密集型任务，任务越多，CPU效率越高，但也有一个限度。

当然为了避免GIL对我们程序产生影响，我们也可以使用，线程锁。

Lock&RLock

常用的资源共享锁机制：有Lock、RLock、Semphore、Condition等，简单给大家分享下Lock和RLock。

Lock

特点就是执行速度慢，但是保证了数据的安全性

RLock

使用锁代码 *** 作不当就会产生死锁的情况。

什么是死锁

死锁：当线程A持有独占锁a，并尝试去获取独占锁b的同时，线程B持有独占锁b，并尝试获取独占锁a的情况下，就会发生AB两个线程由于互相持有对方需要的锁，而发生的阻塞现象，我们称为死锁。即死锁是指多个进程因竞争资源而造成的一种僵局，若无外力作用，这些进程都将无法向前推进。

所以，在系统设计、进程调度等方面注意如何不让这四个必要条件成立，如何确定资源的合理分配算法，避免进程永久占据系统资源。

死锁代码

python线程间通信

如果各个线程之间各干各的，确实不需要通信，这样的代码也十分的简单。但这一般是不可能的，至少线程要和主线程进行通信，不然计算结果等内容无法取回。而实际情况中要复杂的多，多个线程间需要交换数据，才能得到正确的执行结果。

python中Queue是消息队列，提供线程间通信机制，python3中重名为为queue，queue模块块下提供了几个阻塞队列，这些队列主要用于实现线程通信。

在 queue 模块下主要提供了三个类，分别代表三种队列，它们的主要区别就在于进队列、出队列的不同。

简单代码演示

此时代码会阻塞，因为queue中内容已满，此时可以在第四个queueput('苹果')后面添加timeout，则成为 queueput('苹果'，timeout=1)如果等待1秒钟仍然是满的就会抛出异常，可以捕获异常。

同理如果队列是空的，无法获取到内容默认也会阻塞，如果不阻塞可以使用queueget_nowait()。

在掌握了 Queue 阻塞队列的特性之后，在下面程序中就可以利用 Queue 来实现线程通信了。

下面演示一个生产者和一个消费者，当然都可以多个

使用queue模块，可在线程间进行通信，并保证了线程安全。

协程

协程，又称微线程，纤程。英文名Coroutine。

协程是python个中另外一种实现多任务的方式，只不过比线程更小占用更小执行单元（理解为需要的资源）。为啥说它是一个执行单元，因为它自带CPU上下文。这样只要在合适的时机， 我们可以把一个协程 切换到另一个协程。只要这个过程中保存或恢复 CPU上下文那么程序还是可以运行的。

通俗的理解：在一个线程中的某个函数，可以在任何地方保存当前函数的一些临时变量等信息，然后切换到另外一个函数中执行，注意不是通过调用函数的方式做到的，并且切换的次数以及什么时候再切换到原来的函数都由开发者自己确定。

在实现多任务时，线程切换从系统层面远不止保存和恢复 CPU上下文这么简单。 *** 作系统为了程序运行的高效性每个线程都有自己缓存Cache等等数据， *** 作系统还会帮你做这些数据的恢复 *** 作。所以线程的切换非常耗性能。但是协程的切换只是单纯的 *** 作CPU的上下文，所以一秒钟切换个上百万次系统都抗的住。

greenlet与gevent

为了更好使用协程来完成多任务，除了使用原生的yield完成模拟协程的工作，其实python还有的greenlet模块和gevent模块，使实现协程变的更加简单高效。

greenlet虽说实现了协程，但需要我们手工切换，太麻烦了，gevent是比greenlet更强大的并且能够自动切换任务的模块。

其原理是当一个greenlet遇到IO(指的是input output 输入输出，比如网络、文件 *** 作等) *** 作时，比如访问网络，就自动切换到其他的greenlet，等到IO *** 作完成，再在适当的时候切换回来继续执行。

模拟耗时 *** 作：

如果有耗时 *** 作也可以换成，gevent中自己实现的模块，这时候就需要打补丁了。

使用协程完成一个简单的二手房信息的爬虫代码吧！

以下文章来源于Python专栏 ，作者宋宋

文章链接：>

以上就是关于jmeter-线程组全部的内容，包括:jmeter-线程组、XXL admin 源码解析、在C#中如何使用多线程，每隔几秒去执行一个方法等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！