1.FFplay源码分析-nobuffer
2.Kafka源码分析(五) - Server端 - 基于时间轮的延迟源码延迟延时组件
3.一篇讲解CPU性能指标提取及源码分析
4.JDK源码分析Timer/TimerTask 源码分析
5.rocketmq实现延迟队列精确到秒级实现（总结编）
6.跪求 按键精灵8.0如何后台窗口运行 重复 按Z键 延迟10毫秒的源代码~~~写给我的人我祝他兔年发大财~年年发

FFplay源码分析-nobuffer

       在使用 FFplay 播放 RTMP 流时，不开启 nobuffer 选项会导致画面延迟高达7秒左右，代码而开启此选项后，延迟源码延迟局域网延迟可降低到毫秒左右。代码因此，延迟源码延迟本文将深入探讨nobuffer的代码航天源码实现细节，以及播放端缓存7秒数据的延迟源码延迟作用。

       fflags 的代码定义在 libavformat/options_table.h 文件中，这是延迟源码延迟一个通用选项，所有解复用器均包含此选项。代码在调用 avformat_open_input() 函数时，延迟源码延迟会将该命令行参数传入，代码其位置与所有格式参数相同，延迟源码延迟如在之前的代码文章《FFplay源码分析》中所述。记得在调试参数中添加-fflags nobuffer。延迟源码延迟

       在 avformat_open_input() 函数内部，fflags 这个 AVOption 会被传递给 AVClass，该类存储了多个 AVOption，而fflags 的索引为5。在 av_opt_set_dict() 函数中，fflags 的值会被应用并清除其他选项。在 avformat_open_input() 执行完毕后，AVFormatContext::flags 的第7位应被置为1，即二进制的 。通过下图可以清晰地看到这个过程。

       在 avformat_find_stream_info() 函数内部，如果没有设置nobuffer标记，探测的数据包将被丢入队列。avformat_find_stream_info() 首先读取一段数据包以分析输入流的编码器等信息，为了重用这些数据包，它们会被放入队列中。源码破解之家然而，整个探测过程长达5秒，这意味着 FFplay 大概会读取5秒的数据来分析输入流。若开启nobuffer，则不会重复使用这些探测数据，FFplay 探测完输入流后，会读取新的数据包进行播放。无需缓存，从而降低了延迟。

       通过在 ffpaly.c 文件中的 avformat_find_stream_info() 函数前后输出时间，可以发现两者相差5秒，直观展示了nobuffer对于降低延迟的作用。在实时场景下，缓存功能变得多余，它原本是为了分析本地文件，避免重复读取，但在实时场景中反而影响了性能。因此，在实时场景中，关闭缓存更为合适。

       补充说明：若在本地虚拟机环境下，不启用缓存也能实现流畅播放。然而，如果 SRS 部署在局域网的另一台机器上，不开启缓存可能导致视频卡顿，原因可能是解码前未能及时读取视频帧，FFplay 不断丢弃视频帧，尤其是当视频比音频慢时，这种情况下缓存功能反而成为瓶颈。

Kafka源码分析(五) - Server端 - 基于时间轮的餐饮美食源码延时组件

       Kafka内部处理大量的延时操作，例如，在接收到PRODUCE请求后，副本可以等待一个timeout的时间再响应客户端。下面我们来探讨一个问题：为什么Kafka要自己实现一个延时任务组件，而不是直接使用Java的java.util.concurrent.DelayQueue呢？我们可以从以下两个方面来分析这个问题。

       1.1 DelayQueue的能力

       DelayQueue相关的接口/类如下所示：

       相应地，DelayQueue提供的能力如下：

       1.2 Kafka的业务场景

       Kafka的业务背景具有以下特点：

       相应地，Kafka对延时任务组件有以下两点要求：

       这两点要求都无法通过直接应用DelayQueue的方式得到满足。

       二. 组件接口

       让我们来看看Kafka的延时任务组件对外提供的接口，从而了解其提供的能力和使用方式。

       如下所示：

       左边的两个类定义了"延时操作"，右边的DelayedOperationPurgatory类定义了一个维护DelayOperaton的容器，其核心操作如下：

       三. 实现

       以下是关于"延时"实现方式的介绍。

       3.1 业务模型

       时间轮延时组件的思路如下：

       接下来，通过一个具体的例子来说明这种映射逻辑：

       首先关注上图中①号时间轮。圆环中的每一个单元格表示一个TimerTaskList。单元格有其关联的时间跨度；下方的"1s x "表示时间轮上共有个单元格，每个单元格的时间跨度为1秒。有一个指针指向了"当前时间"所对应的单元格。顺时针方向为时间流动方向。

       当收到一个延迟时间在0-1s的TimerTask时，会将其追加到①号时间轮的橙色单元格中。当收到一个延迟时间在3-4s的TimerTask时，会将其追加到①号时间轮的**单元格中。以此类推。

       现在有一个问题：①号时间轮能表示的最大延迟时间是秒，那如果收到了延迟秒的任务该怎么办？这时该用到②号时间轮了，我们称②号为①号的"溢出时间轮"。②号时间轮的特点如下：

       如此，延迟时间在-s的同城源码cmsTimerTask会被追加到②号的紫色单元格，延迟时间在-s的TimerTask会被追加到②号的绿色单元格中。③号时间轮同理。

       刚刚是按①->②->③的顺序来分析时间轮的逻辑，反过来也可以得到有用的想象手里有一个"放大镜"，其实③号时间轮的蓝色单元格"放大"后是②号时间轮；②号时间轮的蓝色单元格"放大"后是①号时间轮；蓝色单元格并不实际存储TimerTask。

       3.2 数据结构

       DelayedOperationPurgatory有一个Timer类型的timeoutTimer属性，用于维护延时任务。实际使用的是Timer的实现类：SystemTimer。该类用于维护延时任务的核心属性有两个：delayQueue和timingWheel。TimingWheel表示单个时间轮，接下来我们来看看其类图：

       各属性含义如下：

       3.3 算法

       3.3.1 添加任务

       添加任务的入口是DelayedOperationPurgatory.tryCompleteElseWatch，其核心逻辑分为如下两步：

       SystemTimer.add直接调用了addTimerTaskEntry方法，后者逻辑如下：

       TimingWheel.add的逻辑也很清晰，分如下4种场景处理：

       3.3.2 尝试提前触发任务

       入口是DelayedOperationPurgatory.checkAndComplete：

       接下来看Watchers.tryCompleteWatched方法的内容：

       DelayedOperation.maybeTryComplete方法最终调用了DelayedOperation.tryComplete；

       DelayedOperation的子类需要在后者中实现自己的"触发条件"检查逻辑；若满足了提前触发的条件，则调用forceComplete方法执行事件触发场景下的业务逻辑。

       3.3.3 任务到期自动执行

       DelayedOperationPurgatory中维护了一个expirationReaper线程，其职责就是循环调用kafka.utils.timer.SystemTimer#advanceClock来从时间轮中获取已超时的任务，并更新时间轮的"当前时间"指针。

       四. 总结

       才疏学浅，未能窥其十之一二，随时欢迎各位交流补充。若文章质量还算及格，可以点赞收藏加以鼓励，后续我继续更新。

       另外，也可以在目录中找到同系列的其他文章：

       感谢阅读。

一篇讲解CPU性能指标提取及源码分析

       这篇报告主要根据CPU性能指标——运行队列长度、调度延迟和平均负载，对系统的性能影响进行简单分析。

       CPU调度程序运行队列中存放的压缩程序源码是那些已经准备好运行、正等待可用CPU的轻量级进程。如果准备运行的轻量级进程数超过系统所能处理的上限，运行队列就会很长，运行队列长表明系统负载可能已经饱和。

       代码源于参考资料1中map.c用于获取运行队列长度的部分代码。

       在系统压力测试前后，使用压力测试工具stress-ng，可以看到运行队列长度的明显变化，从3左右变化到了左右。

       压力测试工具stress-ng可以用来进行压力测试，观察系统在压力下的表现，例如运行队列长度、调度延迟、平均负载等性能指标。

       在系统运行队列长度超过虚拟处理器个数的1倍时，需要关注系统性能。当运行队列长度达到虚拟处理器个数的3~4倍或更高时，系统的响应就会非常迟缓。

       解决CPU调用程序运行队列过长的方法主要有两个方面：优化调度算法和增加系统资源。

       所谓调度延迟，是指一个任务具备运行的条件（进入 CPU 的 runqueue），到真正执行（获得 CPU 的执行权）的这段时间。通常使用runqlat工具进行测量。

       在正常情况下使用runqlat工具，可以查看调度延迟分布情况。压力测试后，调度延迟从最大延迟微秒变化到了微秒，可以明显的看到调度延迟的变化。

       平均负载是对CPU负载的评估，其值越高，说明其任务队列越长，处于等待执行的任务越多。在系统压力测试前后，通过查看top命令可以看到1分钟、5分钟、分钟的load average分别从0.、1.、1.变化到了4.、3.、1.。

       总结：当系统运行队列长度、调度延迟和平均负载达到一定值时，需要关注系统性能并进行优化。运行队列长度、调度延迟和平均负载是衡量系统性能的重要指标，通过监控和分析这些指标，可以及时发现和解决问题，提高系统的稳定性和响应速度。

JDK源码分析Timer/TimerTask 源码分析

       在Java中，Timer 类是实现定时任务的常见工具，配合TimerTask 实现定时、延迟或周期性执行。本文将深入剖析其源码结构和工作原理。

       Timer 的核心机制涉及关键类，包括TimerThread、Timer、TimerQueue 和 TimerTask。一个Timer 实例对应一个TimerThread，负责执行任务；Timer拥有一个TimerThread和一个TimerQueue，而TimerQueue中存储了多个TimerTask。这样的关系可以总结为：

       1个 TimerThread -> 1个线程

       1个 Timer -> 持有 TimerThread 和 TimerQueue

       1个 TimerQueue -> 持有多个 TimerTask

       源码分析时，首先创建Timer时，thread和queue会在声明时初始化为final类型，确保它们与Timer的生命周期绑定。接着，任务通过schedule方法进行调度，这个过程会根据TimerTask类型设置不同的period参数。

       TimerTask 是一个实现了Runnable接口的抽象类，子类需实现run方法。TimerTask的类型决定了其执行周期。TimerThread的run方法包含一个死循环，类似Android的Handler机制。

       TimerQueue作为队列，内部使用完全二叉树结构，add和fixUp方法用于维护最小执行时间的节点在队列前端。purge方法执行后，会调用fixDown方法进行调整。

       总之，每个Timer实例由一个线程和一个二叉堆（通过TimerQueue实现）组成，用于管理定时任务的执行顺序。理解这些核心组件的交互，有助于深入理解Timer的工作机制。

rocketmq实现延迟队列精确到秒级实现（总结编）

       前言篇：

       为节省成本，自研改造RocketMQ，加入任意时间延迟功能的延时队列。开源RocketMQ仅支持等级延迟时间，对大部分功能足够，但因不同供应商订单延迟时间不同（部分分钟取消，有些1.5小时取消），使用大量延时队列。开源版本不支持任意时间延时，查询资料发现基于时间轮实现，但较少开源代码。

       debug实践篇：

       1. 下载源代码，导入IDE，运行生成jar包，配置namesvr和broker运行。

       2. 通过查看文档，执行配置文件修复启动错误，成功运行namesvr和broker。

       3. 运行broker时，需添加配置文件，运行消息发送测试，发现消息无法发送。

       4. 发现还需配置namesvr地址，启动命令添加参数，成功发送消息。

       5. 开发过程充满挑战，通过复制、粘贴代码，处理发送消息逻辑，实现延迟消息功能。

       总结：

       通过时间轮和文件保存延时消息，达到延迟目的。实现方式多样，原理及实现细节可参考相关文章和开源代码。

跪求 按键精灵8.0如何后台窗口运行 重复 按Z键 延迟毫秒的源代码~~~写给我的人我祝他兔年发大财~年年发

       Hwnd = Plugin.Window.Foreground '得到当前窗品句柄

       while true '循环开头

       Call Plugin.Bkgnd.KeyPress(Hwnd,) '按Z键

       Delay '等毫秒

       endwhile '循环末尾

       在要运行的窗口按热键运行,之后最小化什么都行.

阿里面试官：你了解过延迟队列DelayQueue的底层实现原理吗？

       欢迎加入《深入探索Java源码系列》学习，这里我们将一起剖析Java核心组件的底层实现，包括集合、线程、并发与队列等领域，为面试做好充分准备。

       这是系列的第部分，我们将一起研究Java中的DelayQueue，它是一个本地延迟队列，常用于处理在指定时间后执行的任务，如5秒后的定时任务。它的工作原理和使用方式值得深入理解。

       DelayQueue的关键在于它如何管理任务的插入和取出，以及如何根据任务的到期时间进行排序。它基于BlockingQueue接口，提供了四组操作方法，如offer、add、put和take等，满足不同场景需求。同时，它内部使用ReentrantLock保证线程安全，Condition负责处理队列中的条件等待。

       DelayQueue的类结构包括一些重要属性，如元素需实现Delayed接口，以及用于同步的ReentrantLock和Condition。初始化可通过无参构造或指定元素集合的方式进行。下面通过示例来演示如何使用和理解其源码。

       首先，创建一个延迟任务，实现Delayed接口，定义getDelay()和compareTo()方法。运行测试后，任务会按到期时间排序执行，take()方法会阻塞直到有任务到期。

       放数据源码中，offer()方法负责插入元素，如果队列已满，会返回false。其他方法如add、put和offer(e, time, unit)都是基于offer方法实现，各有其特定功能。弹出数据的方法，如poll、remove和take，根据队列状态进行操作，如阻塞或抛出异常。

       总结来说，DelayQueue的核心在于其对任务的排序和等待机制。源码简单明了，但理解其工作原理有助于在面试中应对相关问题。在接下来的文章中，我们还将继续探索其他类型的阻塞队列。