共 6 篇相关文章
这篇讲的是 Android 应用内为何以及如何使用多进程。作者从解决主进程内存压力问题出发，指出当应用处理大图片或频繁绘制时容易 OOM，仅靠 `largeHeap` 增加堆内存只是权宜之计，会影响整机效率。因此，引入了多进程方案：通过在 AndroidManifest.xml 中为组件设置 `android:process` 属性，将特定页面（如视频播放）放入独立进程，以分担主进程内存压力。 文章重点分析了使用多进程后会遇到的“坑”。由于每个进程拥有独立的内存空间，会导致三大核心问题：一是断点调试失效，堆栈不连续，通常需要临时移除 `process` 属性来调试；二是 Activity 管理逻辑（如通过 LinkedList 全局退出应用）失效，因为每个进程会独立运行 Application 的 onCreate；三是进程间无法共享内存，通信和数据共享必须借助 Bundle、AIDL 或文件等跨进程机制。 文章最后指出，虽然多进程能缓解内存问题，但这是一种“下下策”，根本之道还是在于做好应用的性能优化。
这篇讲的是一个专为PHP环境设计的开源监控扩展——witness。它瞄准的是PHP多进程、多机器部署架构下，难以追踪和排查特定用户请求问题的痛点。当线上出现只影响个别用户的故障时，传统加日志的方式往往效率低下且可能引入新问题。 witness的解决方案巧妙而直接：它作为一个底层扩展嵌入PHP引擎，无需修改业务代码。核心能力在于可以通过设置特定的cookie，对来自目标用户的请求进行精准监控。它提供了两种核心模式：trace模式记录完整的函数调用流，像“拍视频”一样还原过程；dump模式则抓取当前调用栈的详细状态，如同“拍照片”保留瞬间细节。 文章详细介绍了系统的三层架构（扩展、数据传输、数据展示），以及具体的安装、配置步骤。扩展以配置项控制行为，如监控深度、是否记录内置函数等，灵活度很高。数据最终会汇总，便于后续可视化分析。 总的来说，witness提供了一套轻量且高性能的非侵入式方案，让PHP开发者能在复杂分布式环境中，更精准、高效地定位那些“幽灵般”的个别用户问题。项目已在GitHub开源。
这篇讲的是Unix/Linux系统编程中核心的I/O模型。作者从基础的read/write操作入手，系统地梳理了五种经典的I/O模型，清晰对比了它们之间的核心差异。 文章的重点在于剖析同步与异步、阻塞与非阻塞这两对关键概念如何交织，形成了阻塞I/O、非阻塞I/O、I/O多路复用、信号驱动I/O和异步I/O这五种形态。它没有停留在概念定义，而是结合了具体的生活化比喻（比如去餐厅吃饭的不同点单方式）和代码执行流程图，让抽象的内核行为变得直观可感。例如，在解释select/poll等多路复用机制时，详细说明了其如何通过“一个线程监视多个描述符”来提升效率，以及其在高并发场景下的局限性。 通过这篇笔记，读者能建立起对不同I/O模型在性能、资源消耗和编程复杂度上的立体认识，从而在设计高并发服务时，能更清楚地权衡选择哪种模型——是追求极致性能而采用epoll，还是为了开发简便使用多线程阻塞模型。它为深入理解网络服务器底层原理打下了扎实的基础。
这篇文章解释了Apache在监听多个端口或多个IP地址的端口时，其内部子进程如何协调工作的机制，核心聚焦在AcceptMutex锁的作用上。 当Apache只监听一个端口时，所有子进程共享同一个监听套接字，由操作系统内核或Apache自身的机制来确保连接请求被高效分配给空闲进程。但当监听范围扩展到多个端口或IP时，情况就变得复杂。此时，需要一种机制来避免多个进程同时竞争同一个端口的连接请求，或者确保每个端口都有进程在监听，从而产生效率问题。 文章引出了AcceptMutex这一关键配置项。它的本质是一种互斥锁，确保在同一时刻只有一个子进程被“唤醒”去处理某个特定监听端口上的新连接。这有效避免了多个进程盲目争抢（即“惊群效应”）造成的资源浪费，也防止了因缺乏调度导致的请求被忽视。理解这一点，对于深入把握Web服务器如何高效处理并发连接，以及如何根据部署场景（如单机多服务）进行调优，都十分关键。
这篇讲的是如何用GDB调试像Nginx这样的多进程程序。作者从自己学习Nginx源码的经历出发，指出多进程程序（尤其是采用fork模型的）给调试带来了新的挑战——普通的GDB启动方式只能跟踪主进程，子进程的代码逻辑和状态往往成为黑箱。 文章详细介绍了几个核心的调试技巧。其一是启动时就明确告诉GDB要跟踪哪个子进程，通过`set follow-fork-mode child`命令，让调试器在fork发生后自动跟随子进程。其二是对于已经运行的进程，使用`gdb attach`命令动态挂载到特定进程号（PID）上，实现对任意进程的调试。文中结合了具体代码片段，比如如何设置断点、查看变量在不同进程中的状态，让整个过程更清晰。 这些方法的关键差异在于调试的切入时机：是提前规划，还是中途介入。对于长期运行的服务如Nginx，动态attach尤其灵活实用。掌握这些技巧后，开发者就能深入到多进程应用的每个角落，精准定位那些隐藏在子进程中的并发问题或状态异常。
这篇文章从PHP作为常驻进程时令人头疼的内存管理问题切入。作者指出，PHP缺乏独立的GC例程和有效的内存管理途径，导致编写SHELL长驻进程时，内存泄漏与耗尽是难以避免的陷阱，程序常常因此意外中止。 针对这一背景，文章聚焦的解决方案是采用CLI模式下的多进程架构。其核心思路在于利用操作系统的进程管理来规避语言本身的缺陷：通过主进程管理多个独立的子进程来执行具体任务。这样，每个子进程拥有独立的内存空间，当任务完成后，其占用的内存可以随进程终止而被系统干净地回收，从而有效避免了主进程内存的无限增长。 文章进一步探讨了这种架构带来的实际好处。多进程模式不仅解决了内存问题，也提升了应用的健壮性——单个子进程的崩溃不会直接导致整个服务的宕机。对于希望利用PHP构建稳定、可靠的命令行工具或常驻服务的开发者而言，这篇文章提供了一套清晰且经得起考验的实践蓝图。
