Hexo

如何实现高吞吐的定时任务处理实现一个定时任务的调度不算太难，一个简单的思路如下：一个存放定时任务的队列，一个按照固定时间间隔扫描的线程，这个线程每隔一段时间扫描队列里的所有任务，如果需要执行就进行调度。 首先，这个任务一定要暴露一些属性，使得线程可以判断某个时刻是否需要执行： 123456789101112131415161718192021222324252627282930public cla

Netty的EventLoopGroup是什么近期看到了一个 手写EventLoopGroup理解原理 的视频，觉得挺有意思的。 EventLoopGroup 与 EventLoop如果查看一下 Netty EventLoopGroup 的继承关系，我们会发现什么： EventLoopGroup 继承了 ScheduledExecutorService，进而也继承了 ExecutorServic

Redis源码分析之sds篇Redis 是 C 语言编写的，C 语言里的字符串其实就是 char *，那 Redis 也是这样实现的吗？ 如果不是的话，Redis 为什么要单独设计数据结构来存储字符串呢？ 传统字符串在 C 语言的传统字符串里，判断字符串结束是通过末尾的 ‘\0’ 标记，这也意味着字符串里不能有该字符，否则会导致字符串提前结束。 12345678910#include <st

Redis源码分析之dict篇在上一篇 Redis长什么样 提到了 Redis 其实用了全局的 hash 表来存储所有的键值对，即下方图示的 dict，dict 中有两个数组，其中 ht[1] 只在 rehash 时候才真正用到，平时都是指向 null，hash 的底层又是使用数组来实现的，那就引出了接下来的几个问题： redis 初始化这个 dict 时数组容量是多少 如果发生了 hash 冲

Redis长什么样我们都知道 Redis 是一个 <key,value> 的键值数据库，也就是一个 Map。我们平时是怎么实现这样一个 Map 的呢？ 用数组，当一个 key 来的时候，首先进行 hash 运算，接着对数据的 length 取余，把这个键值对放在对应位置，这样能以 O(1) 的时间复杂度进行某个 key 的定位。 Redis 对外暴露了五种常见的数据结构，string、

系统性能优化之TCP篇TCP 是一个可以双向传输的全双工协议，常见的 HTTP 等协议都是基于 TCP 实现的。 TCP 数据交互的主要过程有三次握手建立连接，拥塞控制，四次挥手断开连接，接下来分别介绍几个主要过程涉及到的可能优化方向。 文中的配置参数均可通过 sysctl 参数 查看，syn -w 参数=newValue 修改。 三次握手与TFO三次握手建立连接的首要目的是同步序列号。只有同步了

Netty的Mpsc队列如何实现队列是一种 FIFO（先进先出）的数据结构，JDK 中定义了 java.util.Queue 的队列接口，与 List、Set 接口类似，java.util.Queue 也继承于 Collection 集合接口。此外，JDK 还提供了一种双端队列接口 java.util.Deque，我们最常用的 LinkedList 就是实现了 Deque 接口。JDK 提供了一些

Netty如何实现轻量级对象池对于 Netty 这种高吞吐、低延迟的网络框架中，对象（尤其是 ByteBuf）的创建和释放极为频繁。如果每次都通过 new 来创建对象，容易产生以下问题： GC 频繁：大量短生命周期对象会频繁触发 Young GC，影响系统稳定。 延迟抖动：GC 的 Stop-The-World 事件会导致请求延迟不稳定。 内存碎片：频繁的分配和释放会导致堆内存碎片化。 Net

Netty的ByteBuf好用在哪ByteBuf 是 Netty 的数据容器，所有网络通信中字节流的传输都是通过 ByteBuf 完成的。很多开发者已经使用 ByteBuf 代替 ByteBuffer，即便并不是在写一个网络应用，也会单独使用 ByteBuf。 相比 JDK 的 ByteBuffer，Netty 的 ByteBuf 好在哪？ ByteBufferJDK 的 ByteBuffer 结

Netty的FastThreadLocal快在哪Netty 不仅是高性能的网络编程框架，也有很多优秀的设计，譬如本篇要介绍的 FastThreadLocal。 FastThreadLocal 是相比 ThreadLocal 来讲的，那它究竟 fast 在哪？ ThreadLocal实现ThreadLocal 可以用来实现线程内单例。 对于线程内单例，简单的实现可以维护一个 ConcurrentHa