Redis 的基础数据结构（一） 可变字符串、链表、字典
原文地址：https://www.xilidou.com/2018/03/12/redis-data/
这周开始学习 Redis，看看Redis是怎么实现的。所以会写一系列关于 Redis的文章。这篇文章关于 Redis 的基础数据。阅读这篇文章你可以了解：
- 动态字符串（SDS）
- 链表
- 字典
三个数据结构 Redis 是怎么实现的。
线程池 execute() 的工作逻辑
原文地址:https://www.xilidou.com/2018/02/09/thread-corepoolsize/
最近在看《Java并发编程的艺术》回顾线程池的原理和参数的时候发现一个问题，如果 corePoolSize = 0 且 阻塞队列是无界的。线程池将如何工作？
我们先回顾一下书里面描述线程池execute()工作的逻辑：
- 如果当前运行的线程，少于corePoolSize，则创建一个新的线程来执行任务。
- 如果运行的线程等于或多于 corePoolSize，将任务加入 BlockingQueue。
- 如果 BlockingQueue 内的任务超过上限，则创建新的线程来处理任务。
- 如果创建的线程数是单钱运行的线程超出 maximumPoolSize，任务将被拒绝策略拒绝。
看了这四个步骤，其实描述上是有一个漏洞的。如果核心线程数是0，阻塞队列也是无界的，会怎样？如果按照上文的逻辑，应该没有线程会被运行，然后线程无限的增加到队列里面。然后呢？
JAVA 中的 CAS
原文地址：https://www.xilidou.com/2018/02/01/java-cas/
CAS 是现代操作系统，解决并发问题的一个重要手段，最近在看 eureka 的源码的时候。遇到了很多 CAS 的操作。今天就系统的回顾一下 Java 中的CAS。
阅读这篇文章你将会了解到：
- 什么是 CAS
- CAS 实现原理是什么？
- CAS 在现实中的应用
- 自旋锁
- 原子类型
- 限流器
- CAS 的缺点
徒手撸框架--高并发环境下的请求合并
原文地址：https://www.xilidou.com/2018/01/22/merge-request/
在高并发系统中，我们经常遇到这样的需求：系统产生大量的请求，但是这些请求实时性要求不高。我们就可以将这些请求合并，达到一定数量我们统一提交。最大化的利用系统性IO,提升系统的吞吐性能。
所以请求合并框架需要考虑以下两个需求：
- 当请求收集到一定数量时提交数据
- 一段时间后如果请求没有达到指定的数量也进行提交
我们就聊聊一如何实现这样一个需求。
阅读这篇文章你将会了解到:
- ScheduledThreadPoolExecutor
- 阻塞队列
- 线程安全的参数
- LockSupport的使用
徒手撸框架--实现Aop
原文地址:犀利豆的博客
上一讲我们讲解了Spring 的 IoC 实现。大家可以去我的博客查看点击链接，这一讲我们继续说说 Spring 的另外一个重要特性 AOP。之前在看过的大部分教程，对于Spring Aop的实现讲解的都不太透彻，大部分文章介绍了Spring Aop的底层技术使用了动态代理，至于Spring Aop的具体实现都语焉不详。这类文章看以后以后，我脑子里浮现的就是这样一个画面：
我的想法就是，带领大家，首先梳理 Spring Aop的实现，然后屏蔽细节，自己实现一个Aop框架。加深对Spring Aop的理解。在了解上图1-4步骤的同时，补充 4 到 5 步骤之间的其他细节。
读完这篇文章你将会了解：
- Aop是什么？
- 为什么要使用Aop？
- Spirng 实现Aop的思路是什么
- 自己根据Spring 思想实现一个 Aop框架
徒手撸框架--实现IoC
原文地址：https://www.xilidou.com/2018/01/08/spring-ioc/
Spring 作为 J2ee 开发事实上的标准，是每个Java开发人员都需要了解的框架。但是Spring 的 IoC 和 Aop 的特性，对于初级的Java开发人员来说还是比较难于理解的。所以我就想写一系列的文章给大家讲解这些特性。从而能够进一步深入了解 Spring 框架。
读完这篇文章，你将会了解：
- 什么是依赖注入和控制反转
- Ioc有什么用
- Spring的 Ioc 是怎么实现的
- 按照Spring的思路开发一个简单的Ioc框架
2017个人总结
2017年结束了
总的来说2017年是充实的一年，也是在北京从生存逐渐向生活靠拢的一年。
最近遇到的几个问题集合
最近在写项目的时候遇到了几个小问题，记录下来。希望对大家也有所帮助。
Redis RedLock 完美的分布式锁么？
上周花了点时间研究了 Redis 的作者提的 RedLock 的算法来实现一个分布式锁，文章地址。在官方的文档最下面发现了这样一句话。
Analysis of RedLock
Martin Kleppmann analyzed Redlock here. I disagree with the analysis and posted my reply to his analysis here.
突然觉得事情好像没有那么简单，就点进去看了看。仔细读了读文章，发现了一个不得了的世界。于是静下心来研究了 Martin 对 RedLock 的批评，还有 RedLock 作者 antirez 的反击。