1.Netty源码-Reactor线程模型之NioEventLoopGroup研究
2.求按键精灵源代码：随循环次数累加按键次数，源码即第一次循环按Down五次，分析第二次循环按Down十次，源码依此类
3.Vue—关于响应式（二、分析异步更新队列原理分析）
4.死磕以太坊源码分析之挖矿流程
5.剖析std::sort函数设计，源码避免coredump

Netty源码-Reactor线程模型之NioEventLoopGroup研究

       在Netty网络编程中，分析067源码NioEventLoopGroup作为线程池的源码核心组件，其作用至关重要。分析从初始化的源码逻辑分析来看，NioEventLoopGroup扮演多重角色，分析不仅提供了线程池相关功能，源码同时也继承了线程模型的分析ScheduledExecutorService，ExecutorService和Executor接口，源码体现其多功能性。分析

       其层次结构显示，源码NioEventLoopGroup从底层向上层层封装，实现了线程池模型的关键功能。进一步深入分析，NioEventLoopGroup通过继承自MultithreadEventLoopGroup，并在构造函数中执行关键初始化操作，展现了其独特的设计。首先，NioEventLoopGroup在初始化时创建线程工厂，构建线程执行器Executor，如果未提供自定义Executor，将使用DefaultThreadFactory创建FastThreadLocalThread线程执行任务。其次，根据指定数量nThreads创建子线程组，若nThreads未定义或设为0，则默认设置为2倍的CPU线程数。最后，jdk有哪些源码在初始化子线程组时，NioEventLoopGroup通过newChild()方法执行初始化，这一步操作具体实现由NioEventLoop类完成，其初始化参数包括线程选择器chooser，以及其他多个关键参数，确保线程高效运行。

       NioEventLoopGroup与Java线程池之间的区别主要体现在其面向特定应用场景的设计上，尤其在事件驱动和非阻塞IO模型的支持方面。Netty通过NioEventLoopGroup实现了更灵活、高效的并发处理机制，使得在处理高并发、高网络流量场景时，性能得到显著提升。

       在研究NioEventLoopGroup的过程中，我们深入学习到了设计模式的应用，如单例模式确保了线程选择器的唯一性，工厂模式则负责创建不同类型的线程组。此外，模板设计模式的使用，使得NioEventLoopGroup能够提供高度抽象的初始化逻辑，同时保持了代码的复用性和可扩展性。通过这种设计，Netty不仅优化了资源管理，还提升了系统的整体性能和稳定性。

求按键精灵源代码：随循环次数累加按键次数，即第一次循环按Down五次，第二次循环按Down十次，依此类

       方法1

       i=1

       Do

       For i

       KeyPress "Down", 5

       Next

       Delay

       i=i+1

       loop

       方法2

       For i = 1 To i + 1

       For i * 5

       KeyPress "Down", 1

       Next

       TracePrint i

       Delay

       Next

Vue—关于响应式（二、异步更新队列原理分析）

       本节学习要点：Event Loop、Promise

       关于Event Loop的爱蚂蚁教程源码介绍，可以参考阮一峰老师的文章。

       关于Promise，请访问：developer.mozilla.org/z...

       上一节介绍了Vue通过Object.defineProperty拦截数据变化的响应式原理，数据变化后会触发notify方法来通知变更。这一节将继续分析，收到通知后Vue会开启一个异步更新队列。

       以下是两个问题：

       一、异步更新队列

       首先看一段代码演示。

       将上一节的代码拿过来，假设我们现在不仅依赖x，还有y、z，分别将x、y、z输出到页面上。我们现在依赖了x、y、z三个变量，那么我们应该把onXChange函数名改为watch，表示它可以监听变化，而不仅仅是监听一个x的变化。

       可以看到这三个值都被打印在页面上。

       现在我们对x、y、z的value进行修改。

       查看页面，结果没有问题，每个数据的变化都被监听到并且进行了响应。

       既然结果是对的，那我们的javajdk1.8源码问题是什么？

       这个问题是：每次数据变化都进行了响应，每次都渲染了模板，如果数据变化了一百次、一千次呢？难道要重复渲染一百遍、一千遍吗？

       我们都知道频繁操作DOM会影响网页性能，涉及重排和重绘的知识感兴趣请阅读阮一峰老师的文章：ruanyifeng.com/blog/...

       因此，既要保证所有的依赖都准确更新，又要保证不能频繁渲染成为了首要问题。现在我们修改x.value、y.value、z.value都是同步通知依赖进行更新的，有没有一种机制可以等到我修改这些值之后再执行更新任务呢？

       这个答案是——异步。

       异步任务会等到同步任务清空后执行，借助这个特点和我们前面的分析，我们需要：

       按照步骤，我们创建如下代码：

       接着我们需要修改一下notify的代码，监听到数据变化后不立即调用依赖进行更新，而是将依赖添加到队列中。

       回到页面，我们发现页面上还是重复渲染了三次模板。

       那么我们写的这段代码有什么用呢？异步又体现在哪里呢？接着往下看。

       二、nextTick原理分析

       上面的代码中，虽然我们开启了一个队列，并且成功将任务推入队列中进行执行，但本质上还是同步推入和执行的。我们要让它变成异步队列。

       于是到了Promise发挥作用的时候了。关于宏任务和微任务的介绍请参考：zhuanlan.zhihu.com/p/...

       我们创建nextTick函数，nextTick接收一个回调函数，返回一个状态为fulfilled的抛鸡蛋游戏 源码Promise，并将回调函数传给then方法。

       然后只需要在添加任务时调用nextTick，将执行任务的flushJobs函数传给nextTick即可。

       回到页面。

       虽然修改了x、y、z三个变量的value，最后页面上只渲染了一次。

       再来总结一下这段代码的执行过程：

       这也正是Vue采用的解决方案——异步更新队列，官方文档描述得很清楚。

       文档地址：cn.vuejs.org/v2/guide/r...

       三、结合Vue源码来看nextTick

       在Vue中，我们可以通过两种方式来调用nextTick：

       （至于什么时候使用nextTick，如果你不偷懒看了官方文档的话，都能找到答案哈哈）

       以下源码节选自vue2.6.版本，这两个API分别在initGlobalAPI函数和renderMixin函数中挂载，它们都引用了nextTick函数。

       nextTick源码如下：

       在内部，它访问了外部的callbacks，这个callbacks就是前面提到的队列，nextTick一调用就给队列push一个回调函数，然后判断pending（pending的作用就是控制同一时间内只执行一次timerFunc），调用timerFunc()，最后返回了一个Promise（使用过nextTick的应该都知道吧）。

       我们来看一下callbacks、pending、timerFunc是如何定义的。

       可以看到timerFunc函数只是调用了p.then方法并将flushCallbacks函数推入了微任务队列，而p是一个fulfilled状态的Promise，与我们自己的nextTick功能一致。

       这个flushCallbacks函数又干了什么呢？

       flushCallbacks中重新将pending置为初始值，复制callbacks队列中的任务后将队列清空，然后依次执行复制的任务，与我们自己的flushJobs函数功能一致。

       看完上面的源码，可以总结出Vue是这么做的，又到了小学语文之——提炼中心思想的时候了。

       对比一下我们自己写的代码，你学会了吗？

       以上演示代码已上传github：github.com/Mr-Jemp/VueS...

       后面要学习的内容在这里：

       Vue—关于响应式（三、Diff Patch原理分析）

       Vue—关于响应式（四、深入学习Vue响应式源码）

       本文由博客一文多发平台OpenWrite发布！

死磕以太坊源码分析之挖矿流程

       以太坊的挖矿流程主要由miner包负责，它通过miner对象来管理操作，内部使用worker对象实现整体功能。miner决定矿工的启动与停止，并能设置矿工地址以获取奖励。

       worker.go文件中的worker对象负责挖矿的细节，其工作流程包含四个主要循环，通过多个channel完成任务调度、新任务提交、任务结果处理等。

       新任务由newWorkLoop循环产生，此过程中，resubmitAdjustCh与resubmitIntervalCh两个辅助信号用于调整计时器的频率，resubmitAdjustCh根据历史情况计算合理的间隔时间，而resubmitIntervalCh则允许外部实时修改间隔时间。

       mainLoop循环则负责提交新任务并处理结果。TaskLoop提交任务，resultLoop则在新块成功生成后执行相关操作。

       启动挖矿的参数设置定义在cmd/utils/flags.go文件中，提供了一系列选项，如开启自动挖矿、设置并行PoW计算的协程数、配置挖矿通知、控制区块验证、设置Gas价格、确定Gas上限、指定挖矿奖励账户、自定义区块头额外数据、设置重新挖矿间隔等。

       可以采用多种方式启动挖矿，例如通过控制台命令、RPC接口等。设置参数时，可参考官方文档或相关指南进行调整。

       分析代码从miner.go的New函数开始，初始化canStart状态以控制挖矿流程。若Downloader模块正在同步或已完成，则启动挖矿，否则停止。随后进入mainLoop处理startCh，清除旧任务、提交新任务。

       生成新任务通过newWorkCh完成，进入CommitNewWork函数，其中包含组装header、初始化共识字段、创建挖矿环境、添加叔块等步骤。添加叔块时进行校验，确保区块符合规定。若条件允许，任务会提交空块、填充交易，并执行交易以生成最终块。

       交易执行成功后，块数据被存入数据库，并广播至网络。若执行出错，则回滚至上一个快照状态。成功出块后，新区块被验证、确认，并纳入未确认区块集中。若新区块稳定，将正式插入链中。

       整个挖矿流程相对简单，主要由四个循环相互协作完成从挖矿启动到新任务生成、任务提交、成功出块的全过程。共识处理细节将在后续文章中详细阐述。

剖析std::sort函数设计，避免coredump

       剖析STL中的std::sort函数设计，避免coredump

       在STL中，std::sort函数基于Musser在年提出的内省排序（Introspective sort）算法实现。该算法结合了插入排序、堆排序和快速排序的优点。本文将从源码角度深入分析std::sort函数的实现过程。

       std::sort函数在内部调用std::__sort函数。std::__sort主体分为两个部分：快排和堆排。快排通过递归调用__introsort_loop函数实现，堆排则在快排深度达到限制时触发。__introsort_loop函数存在两个限制条件，即快排的最大深度和元素个数的阈值。

       __introsort_loop函数通过while循环执行快排，每次循环寻找分割点后进入右分支递归。在递归回后，进入左分支。该实现避免了调用开销，且减少递归深度过深的情况。当不满足限制条件时，递归返回，留下小于阈值的元素进行后续处理。

       在快排部分，__unguarded_partition_pivot函数负责寻找分割点。它先计算中值，并将其移至数组首部，然后通过while循环调整数组元素，确保左侧元素不比中值大，右侧元素不比中值小。

       __unguarded_partition函数执行快排的分区操作，通过不断调整元素位置，最终实现数组的有序性。为避免越界错误，STL确保中值一定不是最大值，因此分区操作不会越界。

       如果比较器算法不符合严格弱序关系（即当比较器对象comp传入两个相等对象时返回值必须是false），则可能导致coredump。在数据分布为连续相等值时，如果比较器不符合要求，快排过程中可能会导致last指针越界。

       当快排深度达到限制时，STL使用堆排完成排序。__partial_sort函数实现堆排，取出数组中前部分元素并排序。__final_insertion_sort函数则通过插入排序处理局部无序的情况，优化排序速度。

       插入排序在数据主体有序时表现出高效性，STL利用这一点进一步优化排序过程。__insertion_sort函数执行插入排序，通过__unguarded_linear_insert函数寻找合适位置插入元素，实现高效排序。

       在编写自定义比较器算法时，确保其符合严格弱序关系，即当比较器对象comp传入两个相等对象时返回值为false，以避免核心崩溃（coredump）等问题，确保代码移植性。

       至此，我们对std::sort函数的实现流程有了深入理解，避免了由于错误使用导致的coredump问题，实现了更正确的程序设计。