在建设我自己的blog的过程中我意识到我需要有一个任务管理器来定时的执行某些任务，例如访问统计，我将每一个请求记录都记录下来用于后续的一些分析（被DDOS就玩咯，并不是一个好的解决方案），大概每隔5分钟会执行一次。虽然我的任务一般不会有什么太大的变化，但是我想后续在后台的界面上能够看到任务执行的历史，现在的任务列表以及立即执行一个任务的需求。虽然现成的框架是有的，例如Quartz，xxl-job等，但是我还是想自己简单造一个轮子用一下。

最近在做条线的系统重构需要用Java重新实现，除了业务之外我负责进行长连接支持的改造。在具体探讨通用对象池化技术之前简单介绍下我们的系统交互，我们的系统主要服务于保险企业，全国基本大型的保险企业都接入了我们的服务，保险企业通过我们提供的前置程序（类似于SDK）与我们的核心系统交互。我们本次改造的项目便是这个前置程序，我们的客户数量不多，只有一两百家，现在的前置程序通过短链接于核心服务交互，如果在业务量较大的时候会频繁的新建连接，出于性能考虑，我们需要将原来的短连接交互模式调整为长连接交互。 因为连接不释放，因此需要采用一些方法对长连接进行维护，这种方法也就是我们常说的池化技术。本文将对池化技术进行简单的介绍以及探讨通用池化技术应该有哪些API接口。

作者近日在研读Netty的源码，Netty本身内部采用Reactor模式来作为它的核心处理模型，故此想更加深入的了解Reactor模型的产生，以及他解决了什么问题。本文的内容是对Douglas C. Schmidt的《Reactor An Object Behavioral Pattern for Demultiplexing and Dispatching Handles for Synchronous Events》[1]一文的大致翻译，补充了一份可以实际运行的模型代码[3]。在参考文献一栏提供了文件的下载地址。

近日我接到了一个关于FTP监听处理的工单任务，在查阅代码的时候发现原有FTP监听逻辑是需要对FTP和SFTP进行支持的，但是同样的处理流程对FTP和SFTP写了两遍，追究其原因是因为缺少对对FTP和SFTP操作接口的抽象层来屏蔽两者差异。自然而然的会想到使用适配器模式来完成这件工作。