我们知道，I/O 主要指的是磁盘或者网络 I/O（Socket I/O），平常我们讲的 I/O 模型其实说的是 UNIX/Linux 环境下的网络 I/O 模型，这方面讲解比较详细的是 Stevens 的《UNIX Network Programming, Volume 1: The Sockets Networking API, Third Edition》。但是在 POSIX 的标准中，其实只有同步 I/O 和异步 I/O 两种 I/O 模型，它俩的区别就是在整个 I/O 操作完成之前，是否会导致请求进程阻塞。
本文是 Intel 兼容计算机（x86）的内存与保护系列文章的第一篇，延续了启动引导系列文章的主题，进一步分析操作系统内核的工作流程。与以前一样，我将引用 Linux 内核的源代码，但对 Windows 只给出示例（抱歉，我忽略了 BSD，Mac 等系统，但大部分的讨论对它们一样适用）。文中如果有错误，请不吝赐教。
《Redis 设计与实现》更多的是讲解 Redis 的底层，对于实践讲解的较少，适合想深入了解 Redis 的读者。这里总结一下要点，方便随时温习。
公司有一个项目在发布更新时，一直是由开发人员手工选择修改过的源代码文件编译后打包发给实施人员，然后由实施人员到测试环境去替换，如果修改的文件较多，开发人员一个个去查找会比较麻烦，还容易出错，所以就开发了一个小工具，帮助开发人员自动生成增量更新包。
关于 FastDFS 的介绍就先不说了，直接上干货。
LinkedHashMap 继承自 HashMap，在 HashMap 的基础上，通过维护一条双向链表，解决了 HashMap 遍历顺序与插入顺序不一致的问题，除此之外还对访问顺序提供了支持，这在一些场景下是很有用的，比如缓存。
在 JDK 1.8 之前，HashMap 底层使用数组 + 链表的方式实现，在 JDK 1.8 中引入了红黑树来优化链表过长的问题，底层结构就变成了数组 + 链表 + 红黑树。
早期的软件应用在数据库中存储用户密码时，使用的是明文存储，数据库数据泄漏就意味着用户密码的直接暴露。后来通过 MD5 等算法对密码明文进行加密后再存储到数据库中，因为 MD5 算法是不可逆的，即从数学逻辑上来讲无法通过一个加密后的密文反推出原始明文，所以这种方式还算是相对安全的。但是很多用户总是喜欢使用简单易记的密码，这在数据库被脱库，加密后的密文全部暴露的情况下，攻击者可以使用多种方式来破解密码。
在不同的操作系统下，文本文件使用的换行符是不一样的。UNIX/Linux 使用的是 LF，对应的十六进制编码为 0x0A，而 DOS/Windows 使用的是 CRLF，对应的十六进制编码为 0x0D0A。一般的开源项目，源代码都是使用 UNIX/Linux 风格保存的，这么做是为了统一文本风格，使源代码不论在哪个平台下，显示都是一致的。这在多人协作开发，尤其是团队成员使用的平台不同时尤为重要。