解决 ubuntu 的 /etc/hosts 重启就被还原
作者在Ubuntu系统中，为了快速连接公司内部服务器，习惯手动修改/etc/hosts文件来添加IP映射。但每次重启系统后，这些自定义条目总会莫名消失，导致他不得不反复重新配置，影响工作效率。 深入排查后，作者发现问题的根源在于Ubuntu默认集成了systemd-resolved网络服务。这个服务负责统一管理DNS解析和主机名，在系统启动时会自动同步网络状态，从而覆盖了/etc/hosts文件的自定义内容——这是系统维护配置一致性的设计，却成了自定义修改的“拦路虎”。 为了解决这个麻烦，作者找到了两种可靠的方案：一是通过编辑/etc/systemd/resolved.conf文件，设置DNSStubListener参数来禁用服务对hosts的覆盖；二是转向使用netplan配置工具，在配置文件中直接定义静态IP和hosts映射，让系统网络栈从源头接受自定义规则。两种方法都能让修改在重启后保留下来。 调整后，作者的hosts配置终于稳定下来，不再受系统重启的干扰。这篇文章不仅提供了一个具体的故障解决案例，也提醒我们：在使用现代Linux发行版时，了解像systemd-resolved这样的底层服务行为，能帮我们避开许多由系统默认机制引发的配置陷阱。
Tokyo Tyrant 与 Redis 的一些简单比较
这篇博客文章对Tokyo Tyrant和Redis这两款知名的键值存储系统进行了实用对比。作者从实际应用场景出发，剖析了两者在架构设计、性能特点和功能支持上的核心差异。 文章指出，Tokyo Tyrant基于磁盘存储引擎Tokyo Cabinet，强调数据的持久化和可靠性，适合需要大容量存储且对写入速度要求不极端的场景；而Redis以内存为基础，支持丰富的数据结构（如字符串、哈希、列表），在读写速度和实时性上优势明显，常用于缓存和消息队列。作者还提及了各自的网络协议和集群能力差异，例如Redis的发布/订阅功能和Tokyo Tyrant的简单键值操作。 通过这些对比，文章帮助读者理清选择思路：如果应用需要高速缓存或复杂数据操作，Redis更为合适；若更看重持久化和成本控制，Tokyo Tyrant则是值得考虑的选项。整体上，文章以清晰的框架呈现了技术选型的关键考量点。
内存学习――虚拟内存
这篇讲的是虚拟内存的核心机制与设计逻辑。文章紧接上一篇对“为什么需要虚拟内存”的探讨，深入到具体实现层面，解释了操作系统如何通过页表、缺页中断等机制，将进程的逻辑地址空间映射到物理内存，从而构建出一个稳定、隔离且大于实际物理内存的虚拟环境。 作者从进程的视角出发，阐述了虚拟内存如何让每个程序都“错觉”自己拥有连续完整的内存空间，而底层物理内存却可能被分散地分配在不同位置。文中可能会剖析关键的内存管理单元（MMU）工作原理，以及当程序访问的页面不在物理内存时，系统如何通过换入换出机制透明地完成数据调度。 读完这篇文章，你不仅会明白虚拟内存“是什么”，更能理解它“为什么这样设计”——比如如何实现内存保护、简化编程模型，以及在资源有限的系统上高效运行多个进程。这些底层细节是理解现代操作系统性能优化和故障分析的基础。
内存学习――为什么需要虚拟内存
这篇讲的是虚拟内存存在的必要性。作者从自己初学时对物理内存、虚拟内存的模糊认知出发，梳理出两者最核心的差异：物理内存是真实、有限的硬件，而虚拟内存为每个进程提供了一个独立、连续且远大于实际内存的地址空间。文章清晰地解释了这种抽象如何解决进程隔离、内存安全以及高效利用物理内存这几个关键问题，比如让每个程序“以为”自己独占内存，实际上则由操作系统在幕后将虚拟地址映射到真实的物理页帧。作者通过具体的逻辑推导，阐明了虚拟内存作为现代操作系统基石的作用，帮助读者从“为什么”这个源头建立起理解。
关于IO的同步,异步,阻塞,非阻塞
这篇讲的是网络IO模型中几个核心但常被混淆的概念：同步、异步、阻塞与非阻塞。作者从一次团队周会的实际讨论出发，发现大家对这些术语的理解各执一词，甚至连常见的技术资料（如Wikipedia）也常将“异步”与“非阻塞”混为一谈。 文章的核心价值在于对这两对概念进行了系统性的对比与澄清。它明确了“同步/异步”关注的是IO操作完成后，通知机制的差异——是由调用方主动检查，还是由内核完成后通知调用方；而“阻塞/非阻塞”描述的则是调用函数后，在数据未就绪时线程是否挂起等待。作者结合Unix系统调用和epoll的实例，分析了它们在不同网络编程模型下的具体表现与组合方式。 通过厘清这些理论上的区别，文章能帮助开发者更准确地理解`select`、`poll`、`epoll`以及异步IO接口（如`aio`）的设计思想与适用场景，这对于编写高性能的网络服务程序很有启发。
Unix IO模型学习
这篇讲的是作者从学习Java NIO框架的需求出发，系统回顾Unix底层IO模型的学习笔记。 文章聚焦于对比Unix环境下几种经典的IO模型：从最基础的阻塞式IO（BIO），到非阻塞IO、IO多路复用（如select/poll/epoll），再到异步IO（AIO）。作者的核心脉络在于梳理这些模型在处理“等待数据准备”和“数据从内核拷贝到用户空间”这两个阶段时的不同策略，清晰剖析了它们各自的实现思路和性能差异的关键所在。 对于开发者而言，这种对比的价值不仅在于理解NIO为何采用多路复用模型以提高效率，更能直观看到不同方案在应对高并发、多连接场景时的优劣取舍。文章将抽象的概念与具体的实现模型联系起来，对于正在从传统BIO思维转向NIO或Netty的开发者来说，这些底层原理的梳理能带来更清晰的认知。
Java运行时内存模型
这篇文章讲解了Java运行时内存模型的组成部分及其划分逻辑。作者根据《Java虚拟机规范》第二版，将运行时内存按生命周期划分为两类：一类是与整个JVM生命周期一致的内存区域，另一类是与线程生命周期一致的区域。具体而言，内存被分为PC计数器、栈、堆、方法区、运行时常量池和本地方法栈这六个部分。 其中，堆是存放对象实例的核心区域，垃圾收集主要发生在这里；方法区则用于存储已被虚拟机加载的类信息、常量、静态变量等数据。理解每个区域的职责和特点，对于分析应用内存占用、定位内存泄漏问题，或是进行针对性的性能调优，都提供了清晰的底层视角。
apache httpd worker模式工作原理及配置
这篇讲的是Apache httpd服务器中worker模式的运行机制与实际配置。作者从Apache的两种核心工作模式——prefork与worker的区别出发，深入解释了worker模式如何通过多进程与多线程的结合来提升并发处理能力。 具体来说，worker模式启动少量子进程，每个子进程内包含多个线程，由这些线程直接处理客户端请求。这种设计相比传统的prefork模式（每个连接对应一个进程），显著降低了内存消耗，使其在处理大量并发连接时，尤其是静态内容服务场景下，资源效率更高。 文章并未止步于原理，还详细拆解了配置参数的含义与调优逻辑。例如，如何通过设置`ThreadsPerChild`和`ServerLimit`来平衡负载能力与系统资源，以及在不同业务负载下，应该选择prefork还是worker的决策依据。对于运维人员或正在为Web服务器选型的开发者来说，这些对比和配置细节提供了清晰的落地参考。
Spring的BeanFactory体系结构
这篇从Spring IoC容器的核心——BeanFactory出发，梳理了其层次结构与设计哲学。作者没有停留在简单的接口介绍，而是深入到了源码层面，对比了ListableBeanFactory（宽而扁平）与HierarchicalBeanFactory（层级结构）两种核心接口的设计意图，解释了容器如何在灵活性与结构化之间取得平衡。 文章的精彩之处在于对几个关键实现机制的剖析。特别是“三级缓存”机制如何精妙地解决循环依赖问题，让读者看到Spring在看似简单的依赖注入背后所做的复杂设计。同时，对FactoryBean这一扩展点的解读，也揭示了Spring如何允许开发者“劫持”对象的创建过程，使容器能管理更复杂的对象。 总的来说，这篇文章将抽象的容器概念落地到了具体的设计决策与实现代码中，帮助读者真正理解Spring Bean管理这一复杂系统的内在逻辑。