皮皮网

1.物联网设备常见的源码web服务器——uhttpd源码分析（二）
2.Nginx源码分析 - 基础数据结构篇 - 数组结构 ngx_array.c
3.Redis源码解析：一条Redis命令是如何执行的？
4.Andorid进阶一：LeakCanary源码分析，从头到尾搞个明白
5.UE4源码剖析：MallocBinned（上）
6.Lua5.4 源码剖析——性能优化与原理分析

物联网设备常见的分析web服务器——uhttpd源码分析（二）

       uHTTPd 是一个专为 OpenWrt/LUCI 开发者设计的轻量级 Web 服务器，致力于实现稳定高效的内存服务器功能，以适应嵌入式设备的源码特殊需求。它默认与 OpenWrt 的分析配置框架（UCI）整合，成为 OpenWrt Web 管理界面 LuCI 的内存语言源码怎么保存组成部分，同时也能够提供常规 Web 服务器所需的源码全部功能。

       在 uHTTPd 的分析内部结构中，`run_server` 函数是内存核心，其详细实现主要依赖于 `uloop_init` 函数。源码在 `uloop_init` 内，分析`epoll_create` 函数负责创建一个用于监听事件的内存 epoll 文件描述符，它在内核中分配空间来存放感兴趣的源码 socket 文件描述符，用于检测是分析否发生事件。最大关注数量为 ，内存为优化性能提供了良好的基础。详细分析和深入探讨请参考相关资源。

       接下来，`fcntl` 函数通过改变已打开文件的性质来实现对文件的控制，具体操作包括改变描述符的属性，为后续的服务器操作提供灵活性。关于这一函数的使用，详细内容可参考相关技术文档。

       `uh_setup_listeners` 函数在服务器配置中占有重要地位，主要关注点在于设置监听器的回调函数。这一过程确保了当通过 epoll 有数据到达时，能够调用正确的处理函数。这一环节是实现高效服务器响应的关键步骤。

       `setsockopt` 函数被用于检查网络异常后的操作，通过设置选项层次（如 SOL_SOCKET、IPPROTO_TCP 等）和特定选项的值，实现对网络连接的优化与控制。此功能的详细解释和示例请查阅相关开源社区或技术资料。

       `listener_cb` 函数是 uHTTPd 的关键回调函数之一，它在 epoll 事件发生时被调用，用于处理客户端连接。其后，`uh_accept_client` 函数负责实际的连接接受过程，通过 `calloc` 函数分配内存空间，并返回指向新分配内存的指针。这一步骤确保了分配的内存空间被初始化为零，为后续数据处理做好准备。

       `accept` 函数在客户端连接请求处理中扮演重要角色，它从服务器监听的 socket 中接收新的连接请求，并返回一个用于与客户端通信的新的套接字描述符。对于这一函数的具体实现和使用细节，可以参考相关技术论坛或开发者文档。

       `getsockname` 函数用于服务器端获取相关客户端的地址信息，这对于维护连接状态和进行数据传输具有重要意义。此函数的详细用法和示例可查阅相关技术资源。

       `ustream_fd_init` 函数通过回调函数 `client_ustream_read_cb` 实现客户端数据的真正读取，而 `client_ustream_read_cb` 则负责操作从客户端读取的数据，确保数据处理的高效性和准确性。

Nginx源码分析 - 基础数据结构篇 - 数组结构 ngx_array.c

       Nginx的Array结构小巧，主要用于存储小块内存。内核源码分析同步每个元素大小固定，基于Nginx的pool实现数据结构。

       数组基础数据结构定义如下：

       1. elts：指向数组第一个元素的指针

       2. nelts：未使用元素计数器

       3. size：每个元素大小，固定

       4. nalloc：已分配元素总数。当元素不足时，Nginx自动扩容

       5. pool：数组和元素所需内存分配在pool内存池上

       数组实现包括：

       1. ngx_array_create：创建数组，定义元素数量和大小

       2. ngx_array_destroy：销毁数组，检查元素是否在内存池结尾，回收内存

       3. ngx_array_push：获取单个元素

       4. ngx_array_push_n：获取多个元素

       Nginx的Array结构设计简洁，高效管理小块内存，提供灵活的创建、销毁、元素获取功能。

Redis源码解析：一条Redis命令是如何执行的？

       作者：robinhzhang

       Redis，一个开源内存数据库，凭借其高效能和广泛应用，如缓存、消息队列和会话存储，本文将带你探索其命令执行的底层流程。本文将以源码解析的形式，逐层深入Redis的核心结构和命令执行过程，旨在帮助开发者理解实现细节，提升编程技术和设计意识。

       源码结构概览

       在学习Redis源代码之前，首先要了解其主要的组成部分：redisServer、redisClient、redisDb、redisObject以及aeEventLoop。这些结构体和事件模型构成了Redis的核心架构。

       redisServer：服务端运行的核心结构，包括监听socket、数据存储的redisDb列表和客户端连接信息。

       redisClient：客户端连接状态的存储，包括命令处理缓冲区、回复数据列表和数据库句柄。

       redisDb：键值对的数据存储，采用两个哈希表实现渐进式rehash。

       redisObject：存储对象的通用表示，包含引用计数和LRU时间，用于内存管理。

       aeEventLoop：事件循环，管理文件和时间事件的处理。

       核心流程详解

       Redis的执行流程从main函数开始，首先初始化配置和服务器组件，进入主循环处理事件。命令执行流程涉及redis启动、客户端连接、接收命令和返回结果四个步骤：

       启动阶段：创建socket服务器，注册可读事件，进入主循环。

       连接阶段：客户端连接后，接收并处理命令，创建客户端实例。

       命令阶段：客户端发送命令，在线ps网页源码服务端解析并调用对应的命令处理函数。

       结果阶段：处理命令后，根据协议格式构建回复并写回客户端。

       渐进式rehash与内存管理

       Redis的内存管理采用引用计数法，通过对象的refcount字段控制内存分配和释放。rehash操作在Redis 2.x版本引入，通过逐步迁移键值对，降低对单线程性能的影响。当负载达到阈值，会进行扩容，这涉及新表的创建和键值对的迁移。

       总结

       本文通过Redis源码分析，揭示了其命令执行的细节，包括启动流程、客户端连接、命令处理和结果返回，以及内存管理策略。这将有助于开发者深入理解Redis的工作原理，提升编程效率和设计决策能力。

Andorid进阶一：LeakCanary源码分析，从头到尾搞个明白

       内存优化掌握了吗？知道如何定位内存问题吗？面试官和蔼地问有些拘谨的小张。小张回答道：“就是用LeakCanary检测一下泄漏，找到对应泄漏的地方，修改错误的代码，回收没回收的引用，优化生命周期线程的依赖关系。”“那你了解LeakCanary分析内存泄漏的原理吗？”面试官追问。“不好意思，平时没有注意过。”小张心想：面试怎么总问这个，我只是一个普通的程序员。

       前言：

       应用性能优化是开发中不可或缺的一环，而内存优化尤为重要。内存泄漏导致的内存溢出崩溃和内存抖动带来的卡顿不流畅，都在切实影响着用户体验。LeakCanary常用于定位内存泄漏问题，是时候深入理解它的工作机制了。

       名词理解：

       hprof：hprof文件是Java的内存快照文件，格式后缀为.hprof，在LeakCanary中用于内存分析。WeakReference：弱引用，当对象仅被weak reference指向，没有任何其他strong reference指向时，在GC运行时，这个对象就会被回收，不论当前内存空间是否足够。在LeakCanary中用于监测被回收的无用对象是否被释放。Curtains：Square的另一个开源框架，用于处理Android窗口的集中式API，在LeakCanary中用于监测window rootView在detach后的内存泄漏。

       目录：

       本文将从以下几个方面进行分析：

       一，怎么用？

       查看官网文档可以看出，使用LeakCanary非常简单，只需添加相关依赖即可。小微红包源码debugImplementation只在debug模式的编译和最终的debug apk打包时有效。LeakCanary的初始化代码通过ContentProvider进行，会在AppWatcherInstaller类的oncreate方法中调用真正的初始化代码AppWatcher.manualInstall(application)。在AndroidManifest.xml中注册该provider，注册的ContentProvider会在application启动的时候自动回调oncreate方法。

       二，官方阐述

       安装LeakCanary后，它会通过4个步骤自动检测并报告内存泄漏：如果ObjectWatcher在等待5秒并运行垃圾收集后没有清除持有的弱引用，则被监视的对象被认为是保留的，并且可能会泄漏。LeakCanary会将其记录到Logcat中，并在泄漏列表展示中用Library Leak标签标记。LeakCanary附带一个已知泄漏的数据库，通过引用名称的模式匹配来识别泄漏，如Library Leaks。对于无法识别的泄漏，可以报告并自定义已知库泄漏的列表。

       三，监测activity，fragment，rootView和viewmodel

       初始化的代码关键在于AppWatcher作为Android平台使用ObjectWatcher封装的API中心，自动安装配置默认的监听。我们分析了四个默认监听的Watcher，包括ActivityWatcher，FragmentAndViewModelWatcher，RootViewWatcher和ServiceWatcher，分别用于监测activity，fragment，rootView和service的内存泄漏。

       四，ObjectWatcher保留对象检查分析

       LeakCanary通过ObjectWatcher监控内存泄漏，我们深入分析了其检查过程，包括创建弱引用，检查对应key对象的保留，以及内存快照转储和内存分析。

       五，总结

       本文全面分析了LeakCanary的实现原理，从安装、使用到内存泄漏的检测和分析，详细介绍了各个组件的作用和工作流程。通过深入理解LeakCanary，开发者可以更有效地定位和解决内存泄漏问题，优化应用性能。阅读源码不仅能深入了解LeakCanary的工作机制，还能学习到内存泄漏检测的通用方法和技巧。

UE4源码剖析：MallocBinned（上）

       近期着手UE4项目开发，对UnrealEngine已久仰慕，终于得此机会深入探索。鉴于项目内存性能问题，决定从内存分配器着手，深入研读UE4源码。虽个人水平有限，尚不能全面理解，但愿借此机会揭开源码神秘面纱，公司不让看源码让新手朋友们不再感到陌生。

       UE4内存分配器位于硬件抽象层HAL（Hardware Abstraction Layer）中。具体装箱内存分配器代码位于VS项目目录：UE4/Source/Runtime/Core/Private/HAL/MallocBinned。

       分析从ApplePlatformMemory::BaseAllocator开始，可发现Mac平台的默认分配器为MallocBinned，iOS的默认分配器为MallocAnsi。以下将重点分析MallocBinned。

       一、确定对齐方式

       FScopeLock用于局部线程锁，确保线程同步。关于Alignment的确定，通常使用默认值。默认值取决于内存对齐方式，此处默认对齐为8字节。

       二、确定有足够空间来内存对齐

       代码中，SpareBytesCount用于确认空间足够。若分配内存小于8字节，则按Alignment大小匹配箱体；若大于8字节，则按Size + Alignment - sizeof(FFreeMem)匹配箱体。

       三、确定箱体大小

       根据Size的大小，有三种不同的处理方式。k以下的内存分配采用装箱分配，PoolTable中包含个不同大小的池子。

       四、初始化内存池

       分析内存池初始化过程，主要工作包括：确定内存大小，分配内存块，设置内存池基本信息。

       五、内存装箱

       AllocateBlockFromPool从内存池中分配一个Block，实现内存装箱过程。

Lua5.4 源码剖析——性能优化与原理分析

       本篇教程将引导您深入学习Lua在日常编程中如何通过优化写法来提升性能、降低内存消耗。在讲解每个优化案例时，将附上部分Lua虚拟机源代码实现，帮助您理解背后的原理。

       我们将对优化的评级进行标注：0星至3星，推荐评级越高，优化效果越明显。优化分为以下类别：CPU优化、内存优化、堆栈优化等。

       测试设备：个人MacBookPro，配置为4核2.2GHz i7处理器。使用Lua自带的os.clock()函数进行时间测量，以精确到毫秒级别。为了突出不同写法的性能差异，测试通常循环执行多次并累计总消耗。

       下面是推荐程度从高到低的优化方法：

       3星优化：

       全类型通用CPU优化：高频访问的对象应先赋值给local变量。示例：用循环模拟高频访问，每次访问math.random函数创建随机数。推荐程度：极力推荐。

       String类型优化：使用table.concat函数拼接字符串。示例：循环拼接多个随机数到字符串。推荐程度：极力推荐。

       Table类型优化：Table构造时完成数据初始化。示例：创建初始值为1,2,3的Table。推荐程度：极力推荐。

       Function类型优化：使用尾调用避免堆栈溢出。示例：递归求和函数。推荐程度：极力推荐。

       Thread类型优化：复用协程以减少创建和销毁开销。示例：执行多个不同函数。推荐程度：极力推荐。

       2星优化：

       Table类型优化：数据插入使用t[key]=value方式。示例：插入1到的数字。推荐程度：较为推荐。

       1星优化：

       全类型通用优化：变量定义时同时赋值。示例：初始化整数变量。推荐程度：一般推荐。

       Nil类型优化：相邻赋值nil。示例：定义6个变量，其中3个为nil。推荐程度：一般推荐。

       Function类型优化：不返回多余的返回值。示例：外部请求第一个返回值。推荐程度：一般推荐。

       0星优化：

       全类型通用优化：for循环终止条件无需提前计算缓存。示例：复杂函数计算循环终止条件。推荐程度：无效优化。

       Nil类型优化：初始化时显示赋值和隐式赋值效果相同。示例：定义一个nil变量。推荐程度：无效优化。

       总结：本文从源码层面深入分析了Lua优化策略。请根据推荐评级在日常开发中灵活应用。感谢阅读！

Hermes源码分析（二）——解析字节码

        前面一节 讲到字节码序列化为二进制是有固定的格式的，这里我们分析一下源码里面是怎么处理的

        这里可以看到首先写入的是魔数，他的值为

        对应的二进制见下图，注意是小端字节序

        第二项是字节码的版本，笔者的版本是，也即 上图中的4a

        第三项是源码的hash，这里采用的是SHA1算法，生成的哈希值是位，因此占用了个字节

        第四项是文件长度，这个字段是位的，也就是下图中的为0aa，转换成十进制就是，实际文件大小也是这么多

        后面的字段类似，就不一一分析了，头部所有字段的类型都可以在BytecodeFileHeader.h中看到，Hermes按照既定的内存布局把字段写入后再序列化，就得到了我们看到的字节码文件。

        这里写入的数据很多，以函数头的写入为例，我们调用了visitFunctionHeader方法，并通过byteCodeModule拿到函数的签名，将其写入函数表（存疑，在实际的文件中并没有看到这一部分）。注意这些数据必须按顺序写入，因为读出的时候也是按对应顺序来的。

        我们知道react-native 在加载字节码的时候需要调用hermes的prepareJavaScript方法， 那这个方法做了些什么事呢？

        这里做了两件事情：

        1. 判断是否是字节码，如果是则调用createBCProviderFromBuffer，否则调用createBCProviderFromSrc，我们这里只关注createBCProviderFromBuffer

        2.通过BCProviderFromBuffer的构造方法得到文件头和函数头的信息（populateFromBuffer方法），下面是这个方法的实现。

        BytecodeFileFields的populateFromBuffer方法也是一个模版方法，注意这里调用populateFromBuffer方法的是一个 ConstBytecodeFileFields对象，他代表的是不可变的字节码字段。

        细心的读者会发现这里也有visitFunctionHeaders方法， 这里主要为了复用visitBytecodeSegmentsInOrder的逻辑，把populator当作一个visitor来按顺序读取buffer的内容，并提前加载到BytecodeFileFields里面，以减少后面执行字节码时解析的时间。

        Hermes引擎在读取了字节码之后会通过解析BytecodeFileHeader这个结构体中的字段来获取一些关键信息，例如bundle是否是字节码格式，是否包含了函数，字节码的版本是否匹配等。注意这里我们只是解析了头部，没有解析整个字节码，后面执行字节码时才会解析剩余的部分。

        evaluatePreparedJavaScript这个方法，主要是调用了HermesRuntime的 runBytecode方法，这里hermesPrep时上一步解析头部时获取的BCProviderFromBuffer实例。

        runBytecode这个方法比较长，主要做了几件事情：

        这里说明一下，Domain是用于垃圾回收的运行时模块的代理， Domain被创建时是空的，并跟随着运行时模块进行传播， 在运行时模块的整个生命周期内都一直存在。在某个Domain下创建的所有函数都会保持着对这个Domain的强引用。当Domain被回收的时候，这个Domain下的所有函数都不能使用。

        未完待续。。。

RocksDb 源码剖析 (1) | 如何混合 new 、mmap 设计高效内存分配器 arena ?

       本文旨在深入剖析RocksDb源码，从内存分配器角度着手。RocksDb内包含MemoryAllocator和Allocator两大类内存分配器。MemoryAllocator作为基类，提供MemkindKmemAllocator和JemallocNodumpAllocator两个子类，分别集成memkind和jemalloc库的功能，实现内存分配与释放。

       接着，重点解析Allocator类及其子类Arena的实现。基类Allocator提供两个关键接口：内存分配与对齐。Arena类采用block为单位进行内存分配，先分配一个block大小的内存，后续满足需求时，优先从block中划取，以减少内存浪费。一个block的大小由kBlockSize参数决定。分配策略中，Arena通过两个指针（aligned_alloc_ptr_和unaligned_alloc_ptr_）分别管理对齐与非对齐内存，提高内存利用效率。

       分配内存时，Arena通过构造函数初始化成员变量，包括block大小、内存在栈上的分配与mmap机制的使用。构造函数内使用OptimizeBlockSize函数确保block大小合理，减少内存对齐浪费。Arena中的内存管理逻辑清晰，尤其在分配新block时，仅使用new操作，无需额外内存对齐处理。

       分配内存流程中，AllocateNewBlock函数直接调用new分配内存，而AllocateFromHugePage和AllocateFallback函数则涉及mmap机制的使用与内存分配策略的统一。这些函数共同构成了Arena内存管理的核心逻辑，实现了灵活高效地内存分配。

       此外，Arena还提供AllocateAligned函数，针对特定对齐需求分配内存。这一函数在使用mmap分配内存时，允许用户自定义对齐大小，优化内存使用效率。在处理对齐逻辑时，Arena巧妙地利用位运算优化计算过程，提高了代码效率。

       总结而言，RocksDb的内存管理机制通过Arena类实现了高效、灵活的内存分配与管理。通过深入解析其源码，可以深入了解内存对齐、内存分配与多线程安全性的实现细节，为开发者提供宝贵的内存管理实践指导。未来，将深入探讨多线程内存分配器的设计，敬请期待后续更新。

linux内核源码：内存管理——内存分配和释放关键函数分析&ZGC垃圾回收

       本文深入剖析了Linux内核源码中的内存管理机制，重点关注内存分配与释放的关键函数，通过分析4.9版本的源码，详细介绍了slab算法及其核心代码实现。在内存管理中，slab算法通过kmem_cache结构体进行管理，利用数组的形式统一处理所有的kmem_cache实例，通过size_index数组实现对象大小与kmem_cache结构体之间的映射，从而实现高效内存分配。其中，关键的计算方法是通过查找输入参数的最高有效位序号，这与常规的0起始序号不同，从1开始计数。

       在找到合适的kmem_cache实例后，下一步是通过数组缓存（array_cache）获取或填充slab对象。若缓存中有可用对象，则直接从缓存分配；若缓存已空，会调用cache_alloc_refill函数从三个slabs（free/partial/full）中查找并填充可用对象至缓存。在对象分配过程中，array_cache结构体发挥了关键作用，它不仅简化了内存管理，还优化了内存使用效率。

       对象释放流程与分配流程类似，涉及数组缓存的管理和slab对象的回收。在cache_alloc_refill函数中，关键操作是检查slab_partial和slab_free队列，寻找空闲的对象以供释放。整个过程确保了内存资源的高效利用，避免了资源浪费。

       总结内存操作函数概览，栈与堆的区别是显而易见的。栈主要存储函数调用参数、局部变量等，而堆用于存放new出来的对象实例、全局变量、静态变量等。由于堆的动态分配特性，它无法像栈一样精准预测内存使用情况，导致内存碎片问题。为了应对这一挑战，Linux内核引入了buddy和slab等内存管理算法，以提高内存分配效率和减少碎片。

       然而，即便使用了高效的内存管理算法，内存碎片问题仍难以彻底解决。在C/C++中，没有像Java那样的自动垃圾回收机制，导致程序员需要手动管理内存分配与释放。如果忘记释放内存，将导致资源泄漏，影响系统性能。为此，业界开发了如ZGC和Shenandoah等垃圾回收算法，以提高内存管理效率和减少内存碎片。

       ZGC算法通过分页策略对内存进行管理，并利用“初始标记”阶段识别GC根节点（如线程栈变量、静态变量等），并查找这些节点引用的直接对象。此阶段采用“stop the world”（STW）策略暂停所有线程，确保标记过程的准确性。接着，通过“并发标记”阶段识别间接引用的对象，并利用多个GC线程与业务线程协作提高效率。在这一过程中，ZGC采用“三色标记”法和“remember set”机制来避免误回收正常引用的对象，确保内存管理的精准性。

       接下来，ZGC通过“复制算法”实现内存回收，将正常引用的对象复制到新页面，将旧页面的数据擦除，从而实现内存的高效管理。此外，通过“初始转移”和“并发转移”阶段进一步优化内存管理过程。最后，在“对象重定位”阶段，完成引用关系的更新，确保内存管理过程的完整性和一致性。

       通过实测，ZGC算法在各个阶段展现出高效的内存管理能力，尤其是标记阶段的效率，使得系统能够在保证性能的同时，有效地管理内存资源。总之，内存管理是系统性能的关键因素，Linux内核通过先进的算法和策略，实现了高效、灵活的内存管理，为现代操作系统提供稳定、可靠的服务。

模拟器tiny源码分析(8)执行mov指令(五)段寄存器拾遗

       分析模拟器tiny源码中关于mov指令与内存访问的处理

       在分析mov指令时，我们关注到了指令可能访问内存，这自然引出了CPU内存地址的结构问题。内存地址通常由两部分组成：段寄存器和位偏移地址。

       在我们的分析中，大部分关注的都是偏移地址，但事实上，段寄存器通常默认为DS（数据段寄存器），除非通过段跨越前缀修改。

       以mov [bx],h为例，编译后指令序列显示为：0xc7,0x,0x,0x。而如果我们修改段前缀为ss，即mov ss:[bx],h，则指令序列变为：0x,0xc7,0x,0x,0x，这里多出了一字节。

       那么，tiny在处理段前缀时是如何操作的呢？答案是通过宏SEGREG。如果使用了段跨越前缀，参数1会决定使用哪个段寄存器，通常默认为DS；而参数2则决定偏移寄存器1的使用。

       参数3由两部分组成：一部分是偏移寄存器2，另一部分则是内存地址。最终，地址计算方式为：段寄存器* + 偏移寄存器1 + 偏移寄存器2 + 内存地址。这使得指令能够准确指向内存位置。