欢迎来到皮皮网网首页

【酒仙网源码】【双十一红包单页源码】【安卓系统源码都能修改吗】reaper软件源码_repo下载安卓源码

来源:android api 源码下载 时间:2024-11-25 13:48:03

1.licecap可以卸载吗
2.Kafka源码分析(五) - Server端 - 基于时间轮的软件延时组件

reaper软件源码_repo下载安卓源码

licecap可以卸载吗

       licecap可以卸载,它可将屏幕录像的源码源码内容直接保存为高质量GIF动态格式,并且支持特别标记鼠标操作动态效果。下载

       LICEcap是安卓一款简洁易用的动画屏幕录制软件,它可将屏幕录像的软件内容直接保存为高质量(每帧颜色数量可超过)GIF动态格式。并且支持特别标记鼠标操作动态效果。源码源码酒仙网源码支持加入时间显示和标题名称帧及自定义热键功能,下载并自由调整录制窗口大小。安卓

       它除支持GIF动画外,软件LICEcap还支持自身的源码源码无损LCF文件格式。它的下载压缩比高于gif,图像质量也更高(每帧支持的安卓颜色数量可超过),时间标记更准确。软件录制为LCF后,源码源码可通过内置命令行工具转为GIF,下载或直接在REAPER查看。(xbeta注:关于内置命令行工具。运行安装目录下的licecap_cli.exe,可以看到详细使用方式,双十一红包单页源码比如licecap-dfile.lcffile.gif转换)。LICEcap是GPL协议的自由软件(免费、开源),下载包附有源代码。

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的TimerTask会被追加到②号的紫色单元格,延迟时间在-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来从时间轮中获取已超时的任务,并更新时间轮的"当前时间"指针。

       四. 总结

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

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

       感谢阅读。