皮皮网

1.解Go里面的排队排队WaitGroup了解编程语言核心实现源码
2.Semaphore CountDownLatch详解
3.面试突击46：公平锁和非公平锁有什么区别？
4.roamresearch这款笔记软件有何特别之处?
5.Ubuntu单节点SLURM部署
6.ReentrantLock源码详细解析

解Go里面的WaitGroup了解编程语言核心实现源码

       sync.WaitGroup核心实现逻辑简单，主要用于等待一组goroutine退出。等待代码它通过Add方法指定等待的源码goroutine数量，Done方法递减计数。系统计数为0时，排队排队等待结束。等待代码股票app源码githubsync.WaitGroup内部使用了一个state1数组，源码其中只有一个元素，系统类型为[3]uint。排队排队这是等待代码为了内存对齐，确保数据按照4字节对齐，源码从而在位和位平台间兼容。系统

       内部元素采用uint类型进行计数，排队排队长度为8字节。等待代码这是源码为了防止在位平台上对字节的uint操作可能不是原子的情况。使用uint保证了原子操作的执行和性能。在CPU缓存线（cache line）的上下文中，8字节长度可能有助于确保对缓存线的操作是原子的，从而避免数据损坏。

       测试8字节指针的构造，验证了在经过编译器进行内存分配对齐后，如果元素指针的地址不能被8整除，则其地址+4可以被8整除。这展示了编译器层内存对齐的实现细节。

       sync.WaitGroup中的8字节uint采用分段计数的方式，高位记录需要Done的数量，低位记录正在等待结束的计数。

       源码的核心原理包括使用位uint进行计数，通过高位记录需要Done的数量和低位记录等待的数量。当发现count>0时，Wait的goroutine会排队等待。任务完成后，goroutine执行Done操作，直到count==0，完成并唤醒所有等待的goroutine。

       计数与信号量的实现通过根据当前指针的地址确定采用哪个分段进行计数和等待。添加等待计数和Done完成等待事件分别对应sync.WaitGroup的Add和Done方法。等待所有操作完成时，sync.WaitGroup确保所有任务完成。

       为了深入理解这些概念，可以参考相关文章和资源，如关于CPU缓存线大小和原子操作的透明flash 源码讨论。此外，更多源码分析文章可关注特定的公告号或网站，如www.sreguide.com。本篇文章由ArtiPub自动发布平台发布。

Semaphore CountDownLatch详解

       Semaphore信号量用于控制并发访问的数量。它的实现基于AQS的共享锁机制，类似于高速公路收费站。假设收费站有四个通道，而有五个请求发起，只有四个请求能通过通道，其余则需排队等待。如果当前通道有空闲，请求将被允许继续。

       在使用中，Semaphore通常用于流量控制，确保同时处理的请求不超过特定的数量。其构造函数接受两个参数：permits表示信号量的初始数量，fair表示是否为公平模式，默认为非公平。acquire方法允许获取一个或多个信号量，尝试获取时返回true或false，但不会阻塞。timeout方法允许在指定时间内尝试获取信号量，同样返回true或false。

       Release方法则用于释放信号量，它默认释放一个信号量，也可以释放多个，通过permits参数指定释放的数量。

       在Semaphore的实现中，acquire方法调用AQS的addWaiter方法，处理等待队列的添加和唤醒逻辑。进一步深入可查看AQS详解和ReentrantLock源码解析。

       CountDownLatch是另一种用于控制并发访问的工具，其原理也是基于AQS的共享锁机制。它有两种主要用法：一等多和多等一。

       一等多场景下，当前任务需要等待其他多个任务完成后才能继续执行。例如，游戏开始需要所有玩家准备就绪才能开始。多等一场景则相反，多个任务等待一个特定任务完成后才能执行，fresco框架源码类似赛跑前的发令枪。

       CountDownLatch的构造函数用于创建指定数量的CountDownLatch实例，并将state设置为相应数量。await方法用于阻塞等待，直到所有CountDownLatch被释放，即count值为0时才会继续执行。await方法还支持在指定时间内等待，防止因某些原因无法释放所有CountDownLatch而导致的死锁。

       countDown方法用于释放CountDownLatch，每次释放一个，直到count值降至0。

面试突击：公平锁和非公平锁有什么区别？

       从公平的角度来说，Java 中的锁总共可分为两类：公平锁和非公平锁。但公平锁和非公平锁有哪些区别？孰优孰劣呢？在 Java 中的应用场景又有哪些呢？接下来我们一起来看。

正文

       公平锁：每个线程获取锁的顺序是按照线程访问锁的先后顺序获取的，最前面的线程总是最先获取到锁。 非公平锁：每个线程获取锁的顺序是随机的，并不会遵循先来先得的规则，所有线程会竞争获取锁。 举个例子，公平锁就像开车经过收费站一样，所有的车都会排队等待通过，先来的车先通过，如下图所示：

       通过收费站的顺序也是先来先到，分别是张三、李四、王五，这种情况就是公平锁。 而非公平锁相当于，来了一个强行加塞的老司机，它不会准守排队规则，来了之后就会试图强行加塞，如果加塞成功就顺利通过，当然也有可能加塞失败，如果失败就乖乖去后面排队，这种情况就是非公平锁。

应用场景

       在 Java 语言中，锁 synchronized 和 ReentrantLock 默认都是非公平锁，当然我们在创建 ReentrantLock 时，可以手动指定其为公平锁，但 synchronized 只能为非公平锁。tv播放源码 ReentrantLock 默认为非公平锁可以在它的源码实现中得到验证，如下源码所示：当使用 new ReentrantLock(true) 时，可以创建公平锁，如下源码所示：

公平和非公平锁代码演示

       接下来我们使用 ReentrantLock 来演示一下公平锁和非公平锁的执行差异，首先定义一个公平锁，开启 3 个线程，每个线程执行两次加锁和释放锁并打印线程名的操作，如下代码所示：

import?java.util.concurrent.locks.Lock;import?java.util.concurrent.locks.ReentrantLock;public?class?ReentrantLockFairTest?{ static?Lock?lock?=?new?ReentrantLock(true);public?static?void?main(String[]?args)?throws?InterruptedException?{ for?(int?i?=?0;?i?<?3;?i++)?{ new?Thread(()?->?{ for?(int?j?=?0;?j?<?2;?j++)?{ lock.lock();System.out.println("当前线程："?+?Thread.currentThread().getName());lock.unlock();}}).start();}}}

       以上程序的执行结果如下图所示：接下来我们使用非公平锁来执行上面的代码，具体实现如下：

import?java.util.concurrent.locks.Lock;import?java.util.concurrent.locks.ReentrantLock;public?class?ReentrantLockFairTest?{ static?Lock?lock?=?new?ReentrantLock();public?static?void?main(String[]?args)?throws?InterruptedException?{ for?(int?i?=?0;?i?<?3;?i++)?{ new?Thread(()?->?{ for?(int?j?=?0;?j?<?2;?j++)?{ lock.lock();System.out.println("当前线程："?+?Thread.currentThread().getName());lock.unlock();}}).start();}}}

       以上程序的执行结果如下图所示：从上述结果可以看出，使用公平锁线程获取锁的顺序是：A -> B -> C -> A -> B -> C，也就是按顺序获取锁。而非公平锁，获取锁的顺序是 A -> A -> B -> B -> C -> C，原因是所有线程都争抢锁时，因为当前执行线程处于活跃状态，其他线程属于等待状态（还需要被唤醒），所以当前线程总是会先获取到锁，所以最终获取锁的顺序是：A -> A -> B -> B -> C -> C。

执行流程分析公平锁执行流程

       获取锁时，先将线程自己添加到等待队列的队尾并休眠，当某线程用完锁之后，会去唤醒等待队列中队首的线程尝试去获取锁，锁的使用顺序也就是队列中的先后顺序，在整个过程中，线程会从运行状态切换到休眠状态，再从休眠状态恢复成运行状态，但线程每次休眠和恢复都需要从用户态转换成内核态，而这个状态的转换是比较慢的，所以公平锁的执行速度会比较慢。

非公平锁执行流程

       当线程获取锁时，会先通过 CAS 尝试获取锁，如果获取成功就直接拥有锁，如果获取锁失败才会进入等待队列，等待下次尝试获取锁。这样做的好处是，获取锁不用遵循先到先得的规则，从而避免了线程休眠和恢复的操作，这样就加速了程序的执行效率。 公平锁和非公平锁的性能测试结果如下，以下测试数据来自于《Java并发编程实战》：

        从上述结果可以看出，使用非公平锁的网游源码吧吞吐率（单位时间内成功获取锁的平均速率）要比公平锁高很多。

优缺点分析

       公平锁的优点是按序平均分配锁资源，不会出现线程饿死的情况，它的缺点是按序唤醒线程的开销大，执行性能不高。 非公平锁的优点是执行效率高，谁先获取到锁，锁就属于谁，不会“按资排辈”以及顺序唤醒，但缺点是资源分配随机性强，可能会出现线程饿死的情况。

总结

       在 Java 语言中，锁的默认实现都是非公平锁，原因是非公平锁的效率更高，使用 ReentrantLock 可以手动指定其为公平锁。非公平锁注重的是性能，而公平锁注重的是锁资源的平均分配，所以我们要选择合适的场景来应用二者。

       是非审之于己，毁誉听之于人，得失安之于数。

       公众号：Java面试真题解析

       面试合集：/post/

roamresearch这款笔记软件有何特别之处?

       最近，我发现了一个现象，Roam Research 这款笔记软件的异常受欢迎。人们排队等待这款软件的付费版本，甚至愿意支付高额费用购买长期使用权，这让人感到好奇。这是否意味着它是一款不可替代的工具呢？

       Roam Research 的独特之处在于其实现的双向链接功能，这使得我们在做笔记时，可以建立笔记间的关联。如果从笔记A链接到笔记B，我们不仅能够从A到B，还能从B回溯到A，从而获取丰富的上下文信息。然而，这种特性在众多的Zettelkasten应用中已经不是新鲜事。例如，How to take smart notes的作者Sönke Ahrens推荐的免费工具zettelkasten，就是一款支持双向链接的数字版本。

       但Roam Research的开发者Conor White-Sullivan认为，双向链接只是其表面特性。深层特点可能包括了更精准的笔记粒度控制，更开放的平台以及更好的协作性。具体来说，Roam Research允许用户链接到笔记中的特定块，而不是整个笔记，这使得笔记组织更加灵活。同时，Roam Research的在线版本提供了极高的开放性，便于在不同设备间灵活使用。此外，用户可以定制界面，甚至自动化备份笔记，这些特性使得Roam Research在协作方面表现出色。

       罗曼研究的野心不仅仅是一个个人的知识管理工具，而是旨在构建一个连接每个人的第二大脑的超级知识网络。通过引入分享机制，用户可以轻松导入他人创建的内容，这大大简化了知识获取和学习的过程。这种组织方式变革降低了教育门槛，使得任何人只需接触基本的阅读能力，就能学习任何想要的知识和技能。通过交流和融合知识源码，激发了人们的创造欲和好奇心，形成正反馈循环。

       为了鼓励人们生产和分享知识，Roam Research通过降低成本来激发行为。这包括提供便利的备份和共享功能，以及降低知识采集和生产的成本，从而激励人们更积极地参与知识的生产、分享和协作。

       综上所述，Roam Research 的独特之处不仅在于其双向链接功能，更在于它提供了一种全新的知识管理、协作和分享方式，这使得它成为一款极具吸引力的笔记软件。通过提供灵活的笔记粒度控制、开放的平台、协作功能以及激励机制，Roam Research成功地吸引了众多用户，包括那些愿意付费购买长期使用权的用户。

Ubuntu单节点SLURM部署

       本文将指导您在Ubuntu单节点环境下部署SLURM（Simple Linux Utility for Resource Management），从而实现资源调度和作业排队系统，提升计算资源利用率。

       部署环境包括Ubuntu .和核CPU、8个GPU。

       SLURM是一个集资源调度与排队系统于一体的解决方案，用户可在控制节点提交作业，由SLURM控制器根据申请资源将任务分配至计算节点。当资源不足时，作业将自动进入等待队列，直至资源释放，方可执行。

       部署步骤包括安装MUNGE、SLURM，以及配置相关服务。MUNGE作为认证服务，确保进程间能够进行安全的身份验证。SLURM安装时，选择最新版本以确保兼容性和功能性。依赖包安装完成后，下载并编译SLURM源码。

       在部署过程中，无需为SLURM创建额外用户，直接使用root权限配置即可。配置文件修改时，注意将文件路径设置为默认值，并确保MUNGE服务正常运行。

       SLURM配置文件包括slurmctld、slurmd和slurmdbd等服务配置。其中，slurmdbd用于存储用户自定义资源分配规则，如用户同时可使用的GPU数量和最长运行时间等。

       启动MUNGE服务，确保认证机制运行无误。SLURM服务通过配置文件实现资源管理，包括CPU、内存、GPU等。配置slurmdbd数据库，确保用户资源限制信息正确存储。

       根据需求调整slurm.conf文件，设置队列参数，如作业最大运行时间、默认运行时长、资源分配比例等。配置完成后，启动slurmctld、slurmd和slurmdbd服务。

       添加账户、用户和QoS信息，通过sacctmgr命令实现。设置资源分配规则，确保系统资源利用合理。

       使用sbatch命令提交作业，SLURM提供详细文档供后续学习使用。提供一个基础的demo.slurm脚本示例，用于申请资源、激活虚拟环境和执行代码。

       至此，Ubuntu单节点SLURM部署完成，实现了资源的有效调度与作业管理，提高了计算资源的使用效率。

ReentrantLock源码详细解析

       在深入解析ReentrantLock源码之前，我们先了解ReentrantLock与同步机制的关系。ReentrantLock作为Java中引入的并发工具类，由Doug Lea编写，相较于synchronized关键字，它提供了更为灵活的锁管理策略，支持公平与非公平锁两种模式。AQS（AbstractQueuedSynchronizer）作为实现锁和同步器的核心框架，由AQS类的独占线程、同步状态state、FIFO等待队列和UnSafe对象组成。AQS类的内部结构图显示了其组件的构成。在AQS框架下，等待队列采用双向链表实现，头结点存在但无线程，T1和T2节点中的线程可能在自旋获取锁后进入阻塞状态。

       Node节点作为等待队列的基本单元，分为共享模式和独占模式，值得关注的是waitStatus成员变量，它包含五种状态：-3、-2、-1、0、1。本文重点讨论-1、0、1状态，-3状态将不涉及。非公平锁与公平锁的差异在于，非公平锁模式下新线程可直接尝试获取锁，而公平锁模式下新线程需排队等待。

       ReentrantLock内部采用非公平同步器作为其同步器实现，构造函数中根据需要选择非公平同步器或公平同步器。ReentrantLock默认采用非公平锁策略。非公平锁与公平锁的区别在于获取锁的顺序，非公平锁允许新线程跳过等待队列，而公平锁严格遵循队列顺序。

       在非公平同步器的实例中，我们以T1线程首次获取锁为例。T1成功获取锁后，将exclusiveOwnerThread设置为自身，state设置为1。紧接着，T2线程尝试获取锁，但由于state为1，获取失败。调用acquire方法尝试获得锁，尝试通过tryAcquire方法实现，非公平同步器的实现调用具体逻辑。

       在非公平锁获取逻辑中，通过CAS操作尝试交换状态。交换成功后，设置独占线程。当当前线程为自身时，执行重入操作，叠加state状态。若获取锁失败，则T2和T3线程进入等待队列，调用addWaiter方法。队列初始化通过enq方法实现，enq方法中的循环逻辑确保线程被正确加入队尾。新线程T3调用addWaiter方法入队，队列初始化完成。

       在此过程中，T2和T3线程开始自旋尝试获取锁。若失败，则调用parkAndCheckInterrupt()方法进入阻塞状态。在shouldParkAfterFailedAcquire方法中，当前驱节点等待状态为CANCELLED时，方法会找到第一个非取消状态的节点，并断开取消状态的前驱节点与该节点的连接。若T5线程加入等待队列，T3和T4线程因为自旋获取锁失败进入finally块调用取消方法，找到等待状态不为1的节点（即T2），断开连接。

       理解了shouldParkAfterFailedAcquire方法后，我们关注acquireQueued方法的实现。该方法确保线程在队列中正确释放，如果队列的节点前驱为head节点，成功获取锁后，调用setHead方法释放线程。setHead方法通过CAS操作更新head节点，释放线程。acquire方法中的阻塞是为防止线程在唤醒后重新尝试获取锁而进行的额外阻断。

       锁的释放过程相对简单，将state减至0，将exclusiveOwnerThread设置为null，完成锁的释放。通过上述解析，我们深入理解了ReentrantLock的锁获取、等待、释放等核心机制，为并发编程提供了强大的工具支持。