（面试题）什么是死锁？

面试官：小张，说一说死锁，以及死锁的预防

死锁几乎是面试必考的内容之一，本文开始介绍了什么是死锁然后又举哲学家吃饭的例子说明了死锁产生的原因，又介绍了如何使用idea来查看程序是否产生死锁，最后介绍了如何避免死锁的方法

死锁就是有一天你回家，拿着一把钥匙使劲往锁眼里面捅，结果钥匙断里面了，所以你就叫开锁师傅要开锁，结果锁给开死了，这就是死锁了。以上仅仅是玩笑话，以下步入正题。 　　什么是死锁？ 　　要了解什么是死锁，要首先明白一点，锁是用来做什么？Java中的锁说白了，就是为了保证资源安全，确保一次仅有一个线程对共享资源进行修改。（以上仅为个人理解，如有问题，请评论讨论。）那死锁的概念就好理解了，就是有两个及以上的线程对同一个资源进行争夺，结果两个线程没有一个让步，并且没有任何的外力进行协调导致的一种僵局。 　　例1

在 Java 中，死锁（Deadlock）是指两个或多个线程被阻塞，它们在等待彼此持有的资源时陷入了无限期的等待状态，从而导致它们都无法继续执行。简单来说，死锁是多个线程因争夺资源而造成的一种僵局，每个线程都在等待其他线程释放资源，导致所有线程都无法继续执行下去。

死锁(Deadlock)是指两个或多个线程在执行过程中，因争夺资源而造成的一种互相等待的现象，若无外力作用，这些线程都将无法继续执行下去。

软件测试常见面试题：什么是死锁?如何解决？

总结：死锁是一种常见的并发问题，可以通过避免使用多个同步锁、保证获取锁的顺序和使用定时锁等策略来避免。在进行并发编程时，应当尽量避免出现死锁问题，以保障程序运行的稳定性和正确性。死锁是指两个或多个线程相互等待对方持有的锁而不能继续执行，造成代码无法向下进行的情况。由于两个线程都在等待对方释放所持有的锁，因此出现了死锁情况。的锁，也进入临界区并休眠1秒钟，然后试图获取。的锁，进入临界区并休眠1秒钟，然后试图获取。中修改了竞争锁的获取顺序，使其先获取。的锁，从而解除了死锁情况。

摘要： 死锁是多个线程因争夺资源相互等待的僵局。文章通过"转账死锁"案例演示了死锁场景，并解析其四个必要条件：互斥、持有等待、不可抢占和循环等待。提出四大解决方案：1）统一加锁顺序（按资源编号获取）；2）使用tryLock超时机制；3）资源预分配；4）缩小锁范围。推荐开发时采用并发工具包、限制锁作用域，并利用jstack等工具监控线程状态。附思维导图归纳死锁条件与破解策略，强调预防优于检测的并发编程原则。（148字）

死锁是多线程编程中的一个经典问题，它发生在两个或多个线程被无限期地阻塞，且无法继续执行的情况。死锁发生时，因为线程相互等待对方持有的资源，但没有一个线程能够向前推进，导致程序无法正常运行。

为了避免死锁，需要在设计时遵循一定的规范和原则，例如尽量避免嵌套锁，确保同步代码块执行时间尽可能短等，同时也可以使用专门的工具进行死锁检测和分析，帮助我们找到死锁的根本原因并进行相应的优化和调整。条件：一个线程请求资源时，如果已经持有了其他资源，就可以保持对这些资源的控制，直到满足所有资源的要求才释放。等待条件：多个线程形成一种循环等待的关系，每个线程都在等待其他线程所持有的资源，从而导致死锁的产生。，如果需要使用多个锁，请确保它们的获取顺序是一致的，这样可以避免死锁。

什么是死锁？ 所谓死锁，是指多个进程在运行过程中因争夺资源而造成的一种僵局，当进程处于这种僵持状态时，若无外力作用，它们都将无法再向前推进。 因此我们举个例子来描述，如果此时有一个线程A，按照先锁a再获得锁b的的顺序获得锁，而在此同时又有另外一个线程B，按照先锁b再锁a的顺序获得锁。如下图所示： 产生死锁的原因？ 可归结为如下两点： a. 竞争资源 系统中的资源可以分为两类： 可剥夺资源，是指某进程在获得这类资源后，该资源可以再被其他进程或系统剥夺，CPU和主存均属于可剥夺性资源； 另一类资

避免方式：在析构函数里设置。

Go语言接口(interface)是核心特性，采用隐式实现的"鸭子类型"设计，无需显式声明继承关系。接口底层分为eface(空接口)和iface(带方法接口)两种数据结构，存储类型和值信息。值接收者和指针接收者的选择需根据修改需求和性能考量。类型断言通过iface/eface的转换方法实现，动态分派则利用方法地址表完成。接口设计遵循简洁原则，通过多态实现代码复用，空接口interface{}可存储任意类型。掌握接口原理和正确使用方法，是成为优秀Go开发者的关键，也是面试常见考点。

中小规模/简单场景：优先用“定时任务扫描”（实现简单）或“Redis过期回调”（轻量）。中大规模/高可靠场景：必须用“消息队列延迟消息”，结合状态机、幂等设计、重试机制保证可靠性。“最终一致性”优先（允许短暂延迟，但不能漏取消），不阻塞主流程（订单创建、支付等核心操作必须快速响应）。

隔离级别脏读不可重复读幻读性能读未提交(RU)✅✅✅高读已提交(RC)❌✅✅较高可重复读(RR)❌❌✅(InnoDB 可避免)中串行化❌❌❌低特性悲观锁乐观锁思想假设一定会冲突假设大部分不会冲突实现for update、数据库排他锁、Java同步锁版本号 / 时间戳机制并发性能低高适用场景写多、冲突频繁读多写少、冲突少函数运算要避免，隐式转换要小心不等、OR、前模糊，索引基本挂掉联合索引最左前缀，范围之后不再用区分度低索引没用，优化器说了算对比项。

本文介绍了Qt中的QReadWriteLock读写锁在多线程开发中的应用。该锁在读多写少的场景下性能优异，允许多个读线程并发访问，而写操作则具有独占性。文章详细展示了读写锁与普通互斥锁的区别，提供了配置读取器、缓存系统等典型应用场景，并给出了模块化的代码实现方案，包括共享数据类、读线程类和写线程类的完整实现。通过输出示例验证了读操作可并行执行、写操作独占的特点，最后总结了QReadWriteLock的优势和使用场景。

16384=2*1024*8，即2KB，2KB在集群心跳信息传递是不是很大，16384个槽位够用。Redis集群至少需要几个节点？至少需要几个master节点？Redis集群至少需要3个master节点，1master-1slave，Redis集群需要6个节点；1master-2slave，Redis集群需要9个节点，以此类推。数据分片策略：没有使用一致性哈希，而是使用哈希槽分布数据；使用crc16(key) % 16384，计算键key属于哪个槽。