1.Go并发实战--sync WaitGroup
2.你应该知道的源码wait/notify那点事儿
3.wait函数和waitpid的使用和总结
4.从Linux源码看TIME_WAIT状态的持续时间
5.图解Go里面的WaitGroup了解编程语言核心实现源码
6.深度解析sync WaitGroup源码

Go并发实战--sync WaitGroup

       Go语言并发编程中，sync WaitGroup是解析一种极其实用的工具，它类似于Java的源码CyclicBarrier，但作用于协程。解析在处理并发任务时，源码WaitGroup可以帮助我们监控一组协程的解析动态量化红绿指标源码执行状态，以便决定后续操作。源码其基本操作包括Add()增加等待数，解析Done()减少等待数，源码以及Wait()阻塞协程直到所有任务完成。解析下面将通过实例和原理深入探讨WaitGroup的源码使用和工作原理。

       语法基础

       WaitGroup的解析核心功能体现在Add(), Done(), 和 Wait()三个函数上：

       - Add()：增加等待数，可能加1或加n，源码它会调整计数器，解析当计数器为零时，源码等待的协程会被释放。

       - Done()：相当于Add(-1)，用于减少等待数，确保在返回Wait之前计数器为零。

       - Wait()：阻塞当前协程，直到所有任务完成（即计数器为零）才继续执行。

       例如：

       (代码片段)

实现原理

       WaitGroup的内部实现相当简洁，主要由一个结构体组成，其中包含一个计数器和一个信号量。Add()函数会以原子操作更新计数器，如果计数器减为零，所有等待的goroutine会被释放。需要注意的是：

       - 在创建goroutine或调用Wait之前，必须确保Add()的正增量调用已经完成。

       - 如果重用WaitGroup，每次新的等待事件后，必须先完成之前的Wait调用。

源码解析

       Wait()函数的源码实现了协程的阻塞与释放机制，当所有任务完成后，会解除阻塞并继续执行后续代码。

       总结

       sync WaitGroup是Go并发编程中不可或缺的工具，它通过Add(), Done(), 和 Wait()函数协同管理协程，确保并发任务的mvvm架构wpf源码正确执行顺序。掌握其用法和原理，有助于在实际项目中更高效地管理并发任务。

你应该知道的wait/notify那点事儿

       Java的Object类中的wait()和notify()方法在多线程协作中起着关键作用，它们控制着线程间的等待、唤醒和切换。首先，了解线程的六种状态：新建、就绪、运行、阻塞、完成。接着，看一个代码示例：

       看似平凡的代码，却隐藏着问题。当不正确使用synchronized时，wait()和notify()可能会导致异常。这是因为wait()需要在同步代码块中调用，以保证线程间的通信原子性，避免被中断。

       当thread2调用wait后，如果thread1不释放锁，其他线程无法进入同步块。wait会释放锁，但唤醒后会重新获取，确保线程在被唤醒后继续执行。从JVM源码看，wait会放弃锁然后等待唤醒，notify则会选择一个线程唤醒，并尝试获取锁。

       wait()可能会抛出InterruptedException，因为当其他线程调用interrupt()时，wait会在恢复时检查并抛出异常。调用notify()后，线程并不会立即执行，而是根据JVM的默认策略在同步代码块结束时唤醒。

       至于性能影响，wait和notify使用park/unpark机制，测量平差 源码不占用CPU，不影响系统性能。而监视器（Monitor）是每个对象的核心，控制着线程对对象的访问。进入区、拥有者和等待区的概念解释了线程如何在对象锁的控制下交互。

       最后，要注意的是，Thread.sleep()方法会让线程休眠，但不释放监视器，这点与wait和notify不同。

wait函数和waitpid的使用和总结

       当子进程退出时，Linux内核会通过SIGCHLD信号通知父进程。这种情况下，子进程转变为僵尸状态，仅保留基本数据结构以供父进程查询其退出详情。wait和waitpid函数分别用于处理这种情况。

       wait函数的原型是：当调用后，进程会阻塞直到子进程退出，此时会收集子进程信息并销毁，然后返回。status参数可用来存储退出状态，若对详情不感兴趣，可设置为NULL。

       waitpid函数则更具体，用于等待指定的进程结束。它支持参数status来获取子进程状态，以及选项如WNOHANG防止阻塞。Linux中可用的选项包括WNOHANG和WUNTRACED，它们可以组合使用。函数成功返回子进程pid，失败则返回-1。

       了解这些函数的使用对于监控和管理进程至关重要。如果你对如何更深入地掌握，可以关注博主cs_wu在博客园上的文章，或者尝试c++项目实战课程，包括基础架构、公司签到app源码SPDK、内核等技术，以提升专业技能。

       有兴趣进一步学习内核技术的朋友，可以加入技术交流群获取资源，如内核源码学习路线和视频教程。点击链接获取更多详情和福利。

从Linux源码看TIME_WAIT状态的持续时间

       对于Linux系统中TIME_WAIT状态的Socket，长久以来，人们普遍认为其持续时间大约是秒。然而，在实际线上环境中，Socket的TIME_WAIT状态有时会超过秒。这个问题源于一个复杂Bug的分析，促使我深入Linux源码进行探究。

       首先，了解下我们的Linux环境配置，特别是tcp_tw_recycle参数，这对TIME_WAIT状态的处理至关重要。我们设定了tcp_tw_recycle为0，以避免NAT环境下的特定问题。

       接下来，让我们通过TCP状态转移图来理解TIME_WAIT状态。理论上，它会保持2MSL（Maximum Segment Lifetime，即最长报文段寿命）的时间。但具体时长并未在图中明确指出。在源码中，我发现了一个关键的宏定义TCP_TIMEWAIT_LEN，它定义了秒的销毁时间。

       尽管之前我坚信秒的TIME_WAIT状态会被系统回收，但实际遇到的秒案例促使我重新审视内核对TIME_WAIT状态的处理。这个疑问将通过后续的博客分享答案。

       深入源码，我们找到了TIME_WAIT定时器，它负责销毁过期的Socket。当Socket进入TIME_WAIT状态时，取窗口元素源码会触发特定的函数处理，如在不启用tcp_tw_recycle时，处理函数会直接调用inet_twsk_schedule。

       内核通过时间轮机制管理TIME_WAIT状态，每个slot处理大约7.5秒的Socket。如果所有slot都被TIME_WAIT状态占用，可能会导致处理滞后。如果一个slot中的TIME_WAIT数量超过个，剩余的任务将交给work_queue处理，这会导致处理时间延长。

       通过模拟，我们发现即使在slot处理完成后，整个周期可能已经过去了.5秒，这在NAT环境下可能导致问题。PAWS（Protection Against Wrapped Sequences）的保护机制可能会延长TIME_WAIT状态，使得Socket在特定情况下可以复用。

       总的来说，对TIME_WAIT状态的深入理解需要避免刻板印象，因为实际情况可能因为复杂的机制而超出预想。在解决问题时，必须质疑既有的观点，这虽然艰难，但也是学习和成长的过程。

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

       sync.WaitGroup核心实现逻辑简单，主要用于等待一组goroutine退出。它通过Add方法指定等待的goroutine数量，Done方法递减计数。计数为0时，等待结束。sync.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缓存线大小和原子操作的讨论。此外，更多源码分析文章可关注特定的公告号或网站，如www.sreguide.com。本篇文章由ArtiPub自动发布平台发布。

深度解析sync WaitGroup源码

       waitGroup

       waitGroup 是 Go 语言中并发编程中常用的语法之一，主要用于解决并发和等待问题。它是 sync 包下的一个子组件，特别适用于需要协调多个goroutine执行任务的场景。

       waitGroup 主要用于解决goroutine间的等待关系。例如，goroutineA需要在等待goroutineB和goroutineC这两个子goroutine执行完毕后，才能执行后续的业务逻辑。通过使用waitGroup，goroutineA在执行任务时，会在检查点等待其他goroutine完成，确保所有任务执行完毕后，goroutineA才能继续进行。

       在实现上，waitGroup 通过三个方法来操作：Add、Done 和 Wait。Add方法用于增加计数，Done方法用于减少计数，Wait方法则用于在计数为零时阻塞等待。这些方法通过原子操作实现同步安全。

       waitGroup的源码实现相对简洁，主要涉及数据结构设计和原子操作。数据结构包括了一个 noCopy 的辅助字段以及一个复合意义的 state1 字段。state1 字段的组成根据目标平台的不同（位或位）而有所不同。在位环境下，state1的第一个元素是等待线程数，第二个元素是 waitGroup 计数值，第三个元素是信号量。而在位环境下，如果 state1 的地址不是位对齐的，那么 state1 的第一个元素是信号量，后两个元素分别是等待线程数和计数值。

       waitGroup 的核心方法 Add 和 Wait 的实现原理如下：

       Add方法通过原子操作增加计数值。当执行 Add 方法时，首先将 delta 参数左移位，然后通过原子操作将其添加到计数值上。需要注意的是，delta 的值可正可负，用于在调用 Done 方法时减少计数值。

       Done方法通过调用 Add(-1)来减少计数值。

       Wait方法则持续检查 state 值。当计数值为零时，表示所有子goroutine已完成，调用者无需等待。如果计数值大于零，则调用者会变成等待者，加入等待队列，并阻塞自己，直到所有任务执行完毕。

       通过使用waitGroup，开发者可以轻松地协调和同步并发任务的执行，确保所有任务按预期顺序完成。这在多goroutine协同工作时，尤其重要。掌握waitGroup的使用和源码实现，将有助于提高并发编程的效率和可维护性。

       如果您对并发编程感兴趣，希望持续关注相关技术更新，请通过微信搜索「迈莫coding」，第一时间获取更多深度解析和实战指南。

跟着大佬学JavaScript之lodash防抖节流合并

       前面已经对防抖和节流有了介绍，这篇主要看lodash是如何将防抖和节流合并成一个函数的。

       初衷是深入lodash，学习它内部的好代码并应用，同时也加深节流防抖的理解。这里会先从防抖开始一步步往后，由简入繁，直到最后实现整个函数。

       这里纯粹自己的理解，以及看了很多篇优质文章，希望能加深对节流防抖的理解，如果有不同意见或者看法，欢迎大家评论。

       防抖的原理：在wait时间内，持续触发某个事件。第一种情况：如果某个事件触发wait秒内又触发了该事件，就应该以新的事件wait等待时间为准，wait秒后再执行此事件；第二种情况：如果某个事件触发wait秒后，未再触发该事件，则在wait秒后直接执行该事件。

       通俗点说：定义wait=，持续点击按钮，前后点击间隔都在3秒内，则在最后一次点击按钮后，等待3秒再执行func方法。如果点击完按钮，3秒后未再次点击按钮，则3秒后直接执行func方法。

       节流的原理：持续触发某事件，每隔一段时间，只执行一次。

       通俗点说，3 秒内多次调用函数，但是在 3 秒间隔内只执行一次，第一次执行后 3 秒 无视后面所有的函数调用请求，也不会延长时间间隔。3 秒间隔结束后则开始执行新的函数调用请求，然后在这新的 3 秒内依旧无视后面所有的函数调用请求，以此类推。

       简单来说：每隔单位时间（ 3 秒），只执行一次。

       首先看源码最前方的引入。

       isObject方法，直接拿出来，

       root的引入主要是window。为了引出window.requestAnimationFrame。

       window.requestAnimationFrame()告诉浏览器希望执行动画并请求浏览器在下一次重绘之前调用指定的函数来更新动画，差不多 ms 执行一次。

       lodash这里使用requestAnimationFrame，主要是用户使用debounce函数未设置wait的情况下使用requestAnimationFrame。

       由代码const useRAF = (!wait && wait !== 0 && typeof window.requestAnimationFrame === 'function')不难看出,函数未传入wait并且window.cancelAnimationFrame函数存在这两种情况下操作window.requestAnimationFrame

       其实可以在代码中加上判断同时为false时，默认wait=0，直接执行window.requestAnimationFrame部分,而不是定时器。

       首先，我们可以先来看lodash throttle部分源码:

       其实就是将wait传入了debounce函数的option.maxWait中。所以最后，我们只需要将之前的代码加上maxWait参数部分。

       下面我们分析下maxWait新增的那部分代码。

       1.新增变量就不多说了。

       2.从options中取出maxWait:

       3.计算仍需等待的时间

       首先判断是否节流（maxing）： 1. 是=>取「剩余等待时间」和「距上次执行 func 的剩余等待时间」中的最小值。 2. 否=>取剩余等待时间

       这里是不是就是节流中

       4.判断是否立即执行 lodash代码：

       就往下执行。

       这里是不是就是节流中

       就往下执行。

       5.有maxing时，应该如何处理函数 lodash代码：如果是节流函数就执行

       节流函数中：

       总之，lodashmaxWait部分，尽管参数名多，但实际上就是节流函数中，判断剩余时间remaining。不需要等待，就直接立即执行，否则就到剩余时间就执行一次，依次类推。

       可以去

       查看演示代码

       跟着大佬学系列

       主要是日常对每个进阶知识点的摸透，跟着大佬一起去深入了解JavaScript的语言艺术。

       后续会一直更新，希望各位看官不要吝啬手中的赞。

       ❤️感谢各位的支持！！！

       ❤️如果有错误或者不严谨的地方，请务必给予指正，十分感谢！！！

       ❤️喜欢或者有所启发，欢迎 star！！！