前言

现如今的互联网应用大都是采用 分布式系统架构 设计的，所以 消息队列 已经逐渐成为企业的应用系统 内部通信 的核心手段，

它具有 低耦合、可靠投递、广播、流量控制、最终一致性 等一系列功能。

当前使用较多的 消息队列 有 RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMQ 等，而部分数据库 如 Redis、MySQL 以及 phxsql ，如果硬搞的话，其实也可实现消息队列的功能。

可能有人觉得，各种开源的 MQ 已经足够使用了，为什么需要用 Redis 实现 MQ 呢？

有些简单的业务场景，可能不需要重量级的 MQ 组件（相比 Redis 来说，Kafka 和 RabbitMQ 都算是重量级的消息队列）

那你有考虑过用 Redis 做消息队列吗？

这一章，我会结合消息队列的特点和 Redis 做消息队列的使用方式，以及实际项目中的使用，来和大家探讨下 Redis 消息队列的方案。

1、上下文切换

上下文定义

cpu发生进程或者线程切换时，所依赖的数据集合，比如一个函数有外部变量，函数运行时，必须获取外部变量，这些变量值的集合就是上下文。

引发问题

对于CPU密集型任务，多线程处理会发生上下文切换，会影响到执行速度，如果时IO密集型，多线程技术优点尽显。

如何减少上下文切换

无锁并发编程，锁的获取与释放会发生上下文切换，多线程时会影响效率。无锁并发编程就是将数据分块，每个线程处理各自模块。比如LongAdder中部分代码。 CAS算法，并发编程时通过CAS算法更新数据，而不必加锁。如Java的atomic包下的工具类。 使用最少线程，减少不必要的线程创建，自定义线程池。 使用协程，在单线程中维护多任务调度，处理任务间切换，Golang对于协程的使用很强大。

2、死锁

死锁定义

死锁是进程死锁的简称，是由Dijkstra于1965年研究银行家算法时首先提出来的。 系统发生死锁现象不仅浪费大量的系统资源，甚至导致整个系统崩溃，带来灾难性后果。

产生死锁原因

系统资源不足 进程推进顺序不当 资源分配不合理

死锁产生的必要条件

互斥条件：一个资源只能被一个进程或者线程使用。 请求和保持条件：一个进程或者线程，请求资源的时候发生阻塞，对已经获取的资源保持不放。 不可剥夺条件：进程或者线程以获得的资源，在未使用完成时，不能强行剥夺。 循环等待条件：若干进程或者线程形成一种头尾相接的循环等待的资源关系。

这四分条件是死锁产生的必要条件，只要发生死锁，这些条件必然成立，而只要上述条件之一不满足，就不会发生死锁。

如何避免死锁

1. 以确定的顺序获得锁
2. 加锁时限

Lock接口提供了boolean tryLock(long time, TimeUnit unit) throws InterruptedException方法，该方法可以按照固定时长等待锁，因此线程可以在获取锁超时以后，主动释放之前已经获得的所有的锁。

读者福利

由于篇幅过长，就不展示所有面试题了，感兴趣的小伙伴

更多笔记分享

KsY5v-1618381923371)]

[外链图片转存中…(img-GIuJeiGi-1618381923374)]

更多笔记分享