1.Դ?源码벹?? ???????
2.Redis 实际应用中的异常场景及其根因分析和解决方案
3.linux内核源码：内存管理——内存分配和释放关键函数分析&ZGC垃圾回收
4.从 ExoPlayer 源码分析视频无法播放问题
5.如何有效的做Code Review?
6.故障分析 | 从 Insert 并发死锁分析 Insert 加锁源码逻辑
Դ?벹?? ???????
本文深入解析LiveData在Android开发中的实现机制及用法，内容涵盖LiveData的补丁生命周期感知、观察者注册、根因事件回调机制、分析数据更新以及解决粘性事件问题。源码通过分析LiveData的补丁通达信主图底部源码源码，以期读者能够深入理解LiveData的根因运作原理，从而在实际开发中灵活运用。分析
首先，源码LiveData是补丁一种数据存储类，与传统的根因可观察类相比，具有生命周期感知能力。分析这意味着LiveData只会更新处于活跃生命周期状态的源码组件观察者，确保了数据的补丁实时性和安全性。其感知能力基于LifecycleOwner接口，根因使得活动组件能够安心观察LiveData，无需担心组件生命周期变化导致的数据泄露。
在注册观察者时，LiveData内部通过LifecycleBoundObserver进行封装，确保只有处于活跃状态的组件才能成功注册。当组件进入DESTROYED状态时，观察者会自动移除，从而实现自动取消注册，避免了额外的代码实现。
当组件状态发生改变时，LiveData会通过Lifecycle的onStateChanged方法通知其内部的LifecycleBoundObserver，从而触发观察者回调。观察者在被移除或组件状态改变为DESTROYED时，不会收到任何通知。这确保了数据的实时性和组件的资源管理。
对于数据更新，LiveData提供postValue和setValue方法。setValue直接在主线程执行，而postValue则在主线程执行后调用setValue，确保数据更新的同步性。这些方法最终都会触发观察者回调，实现数据的实时更新。
观察者永久订阅（observeForever）机制则确保了即使观察者在组件销毁后被重新创建，也能接收到数据更新。通过AlwaysActiveObserver类实现，该类不依赖于组件的生命周期状态，确保了观察者状态的始终活跃。
在处理粘性事件时，LiveData通过在考虑通知方法中进行版本判断，确保只在观察者版本更新时发送数据。当新观察者订阅时，其版本尚未被初始化，导致旧值发送，这是粘性事件发生的根本原因。解决这一问题，需要确保观察者版本的正确性，避免不必要的数据发送。
综上，LiveData的pinyinime源码笔记源码解析涵盖了其核心机制、注册与取消注册流程、事件回调机制、数据更新方式以及解决粘性事件的方法。通过深入理解LiveData的工作原理，开发者能够在实际项目中高效地管理数据更新和组件生命周期，实现更加流畅和安全的用户体验。
Redis 实际应用中的异常场景及其根因分析和解决方案
上文较为详尽地阐述了基于 Redis 的分布式缓存实现方案，解答了“如何运用”的问题。然而，在实际应用中，各类异常状况层出不穷，作为开发者，不仅需掌握 Redis 的使用，还应具备定位与解决应用中异常问题的能力。本文将聚焦于 Redis 实际应用中常见的异常场景，包括 Redis 进程无法启动、故障倒换失败、Slot 分配错误等，并深入分析其根本原因与解决策略。
首先，探讨 Redis 进程无法启动的异常情况。假设在一个项目中，Redis 集群作为分布式缓存，其部署环境为 Suse Linux。在迭代验证过程中，项目组发现集群部署偶发失败，部分节点的 redis-server 进程未能正常启动。手动启动 redis-server 时，出现“找不到 GLIBC_2. 版本库”的错误。通过检查系统 GLIBC 版本，发现安装环境仅支持 GLIBC_2.，低于 redis-server 需要的 2. 版本。此问题的根源在于高版本编译与低版本安装之间存在不兼容性。解决方案需统一编译环境和安装环境，或在 Redis 源代码中显式指定 memcpy 函数的 GLIBC 版本。
其次，解析 OpenSSL 版本不兼容导致的 Redis 进程启动失败。在引入证书机制后，安装环境（CentOS 6.2）的 OpenSSL 版本低于编译环境，两者不兼容，引发 redis-server 启动失败。通过查询 OpenSSL 版本，定位到编译环境与安装环境的版本差异是问题的根源。解决方案是将 OpenSSL 的依赖打入 redis-server，使其与操作系统解耦。
进一步分析 Redis 进程拉起失败的场景。集群模式下，宕机节点修复后，redis-server 进程无法启动。问题根因在于宕机节点上的 Redis 集群配置文件（nodes-xxx.conf）存在错误，导致加载配置文件时出现异常。修改源码，增加校验机制，指标源码分类可防止此类错误发生，确保宕机节点的自愈能力。
讨论 Slot 指派报错的解决方案。当 Slot 指派出现错误时，通常由清理信息不彻底导致。解决方法包括清理残留信息或修改源码逻辑，确保 Slot 指派的准确性和稳定性。
最后，面对防火墙、IP 限制导致的 Redis 节点间通信异常，引起单通问题。此类问题源于节点间通信被阻断，影响混合路由查询的正常进行。解决方案需优化网络配置或采用其他通信策略，确保集群中节点间的稳定通信。
总结而言，面对 Redis 实际应用中的异常场景，开发者需深入理解其根本原因，并采取相应的解决策略。通过不断优化部署环境、更新依赖库、强化配置管理以及改进网络配置，可以有效提升 Redis 集群的稳定性和可靠性，确保分布式缓存系统的高效运行。
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队列，寻找空闲的对象以供释放。整个过程确保了内存资源的高效利用，避免了资源浪费。ym点播源码
总结内存操作函数概览，栈与堆的区别是显而易见的。栈主要存储函数调用参数、局部变量等，而堆用于存放new出来的对象实例、全局变量、静态变量等。由于堆的动态分配特性，它无法像栈一样精准预测内存使用情况，导致内存碎片问题。为了应对这一挑战，Linux内核引入了buddy和slab等内存管理算法，以提高内存分配效率和减少碎片。
然而，即便使用了高效的内存管理算法，内存碎片问题仍难以彻底解决。在C/C++中，没有像Java那样的自动垃圾回收机制，导致程序员需要手动管理内存分配与释放。如果忘记释放内存，将导致资源泄漏，影响系统性能。为此，业界开发了如ZGC和Shenandoah等垃圾回收算法，以提高内存管理效率和减少内存碎片。
ZGC算法通过分页策略对内存进行管理，并利用“初始标记”阶段识别GC根节点（如线程栈变量、静态变量等），并查找这些节点引用的直接对象。此阶段采用“stop the world”（STW）策略暂停所有线程，确保标记过程的准确性。接着，通过“并发标记”阶段识别间接引用的对象，并利用多个GC线程与业务线程协作提高效率。在这一过程中，ZGC采用“三色标记”法和“remember set”机制来避免误回收正常引用的对象，确保内存管理的精准性。
接下来，ZGC通过“复制算法”实现内存回收，将正常引用的对象复制到新页面，将旧页面的数据擦除，从而实现内存的高效管理。此外，通过“初始转移”和“并发转移”阶段进一步优化内存管理过程。最后，在“对象重定位”阶段，完成引用关系的更新，确保内存管理过程的完整性和一致性。
通过实测，ZGC算法在各个阶段展现出高效的内存管理能力，尤其是标记阶段的效率，使得系统能够在保证性能的同时，有效地管理内存资源。doc system源码总之，内存管理是系统性能的关键因素，Linux内核通过先进的算法和策略，实现了高效、灵活的内存管理，为现代操作系统提供稳定、可靠的服务。
从 ExoPlayer 源码分析视频无法播放问题
面对项目中出现的视频无法播放问题，我们在ExoPlayer三方库中发现了Decoder init failed的常见错误，即（ERROR_CODE_DECODER_INIT_FAILED）。在Google搜索未果后，我们决定深入源码以寻找问题根源。最终，通过源码分析，我们找到了问题所在并找到了解决方案，希望能为遇到类似问题的读者提供帮助。
对比应用，我们发现使用ExoPlayer播放动态壁纸在多个机型上均能正常工作，这有助于排除机型因素。随后，我们引入ExoPlayer库并创建了一个简单的Demo，测试对比后发现，虽然在特定机型上可以播放网络视频链接，但无法播放我们的视频链接。这提示我们可能是在视频格式上存在问题。
在源码分析中，我们发现MediaCodecVideoRenderer抛出的ExoPlaybackException是问题的关键。从调用栈关系可以看出，问题最终归咎于MediaCodecRenderer的maybeInitCodecWithFallback()方法。深入源码分析后，我们发现initCodec()方法调用时出现了异常，进一步导致了DecoderInitializationException。异常信息与日志显示一致，我们继续追踪initCodec()的逻辑。
通过断点调试，我们发现逻辑最终到达了DefaultMediaCodecAdapterFactory的createAdapter()方法，进一步跟进到SynchronousMediaCodecAdapter.Factory中的createAdapter()方法，最终调用了MediaCodec的configure()方法，导致异常。从源码中可以看出，无论逻辑是否执行到特定的if条件，最终都会调用到MediaCodec方法，因此无需关注if逻辑。
我们意识到最终调用的是C/C++代码，通常在Android端遇到此类异常时似乎无能为力。然而，我们从另一个角度思考问题，即在能够播放视频的机型和无法播放的机型之间是否存在参数差异。通过逐步回溯排查MediaCodecInfo对象的值，我们最终发现了关键逻辑代码。
分析后，我们得知首先通过getAvailableCodecInfos()方法获取一组可用解码器列表，然后通过逻辑判断将列表中的所有解码器或第一个添加到队列availableCodecInfos中。接下来，通过while循环不断从availableCodecInfos队列中取出第一个解码器进行初始化尝试，直到找到成功初始化的解码器为止。
从代码注释中，我们了解到enableDecoderFallback参数的含义，设置为true可能导致性能降低（软解性能不如硬解），但默认情况下优先初始化硬解。通过设置setEnableDecoderFallback(true)，问题得以解决，从而实现了视频的正常播放。
如何有效的做Code Review?
什么是Code Review？Code Review代码评审是指在软件开发过程中，通过对源代码进行系统性检查的过程。通常的目的是查找各种缺陷，包括代码缺陷、功能实现问题、编码合理性、性能优化等；保证软件总体质量和提高开发者自身水平。 Code Review是轻量级代码评审，相对于正式代码评审，轻量级代码评审所需要的各种成本要明显低得多，如果流程正确，它可以起到更加积极的效果。正因如此，轻量级代码评审经常性地被引入到软件开发过程中。
为什么Code Review？
1.提高代码质量。
2.及早发现潜在缺陷，降低修改/弥补缺陷的成本。
3.促进团队内部知识共享，提高团队整体水平。
4.评审过程对于评审人员来说，也是一种思路重构的过程。帮助更多的人理解系统。
5.是一个传递知识的手段，可以让其它并不熟悉代码的人知道作者的意图和想法，从而可以在以后轻松维护代码。
6.鼓励程序员们相互学习对方的长处和优点。
7.可以被用来确认自己的设计和实现是一个清楚和简单的。
如何做Code Review？
Code Review检查什么？
1.结构问题
代码最大的问题，不是一两个地方有技术缺陷，也不是业务逻辑错误，而是整个软件设计的不好。前两者更容易通过测试或使用来发现和更正，但后者就不同了。如果回想一下自己见过的各种烂摊子，是不是有同感？具体哪里有问题怎么改说不上来，就是整个软件看上去混乱无章，无从下手。
具体结构问题包括：重复拷贝代码（不封装函数，不用Template/泛型），函数过长（超过一屏幕就叫过长），错误封装（不恰当的public/不用Interface/不内聚/强耦合/在类中封装了无关方法），内容错误（多个无关类置于一个文件/不恰当的命名）等等。
改正结构问题，是从编写可靠软件向编写精美软件迈进的重要方法。
2.业务逻辑问题
就是软件是否与需求的要求符合的问题。审核者和被审核者经常对业务需求的理解有差异，借此机会同步一下，必要时引入PO（产品经理/产品负责人）。
有人会说业务逻辑问题不是一测试就知道了吗？可是测试一般发生在很久以后，有些逻辑测试还需要一定的触发条件，而且测试只会发现失效（failure, 与预期不符）而不能发现缺陷（defect, 具体哪里出了错），等积累长了，谁也找不到原因了。
3.编程素养问题
很多问题属于那种这样也行那样也行的状态，比如命名/初始值/缩进/断行但是高手的做法总是比新手好一些。
比如boolresult = true; 这句话就有问题，刚初始化就先宣布成功，必有隐患。这是一个真实案例，而下面也的确有一个分支错误地返回了这个true（实际案例是个HRESULT）。而发现这个问题，不是测试而是代码检查。实际上测试几乎发现不了这些问题，比如上面那段代码会在某文件打不开的时候错误地返回这个true，而在测试中几乎不会故事破坏那个文件来测试其结果。
经常进行Code Review
常见的Code Review是高手审核新手，或者师傅走查徒弟。一般而言，大致高手每天能编写多行有效代码（按分号计数），新手会多一些但也不超过（他们编写代码比较费），也就是个屏幕以内。有经验的人一定知道：高手看新手的代码，5秒钟就能发现问题。所以不用花上很长时间去做Code Review，而应该少吃多餐，每次可以5分钟，分钟，每天2-3次甚至更多。看到一个问题就要彻底解决，不需要一次检查很多，问题一次比一次少即可。
但是切记不可积累，隔很长时间才去做Code Review，你就会面临那近万行的代码，以前N多掺和在一起的功能，你会发现，整个Code Review变得非常地艰难，用不了一会儿，你就会发现你会疲惫地打着哈欠，但还是要坚持，有时候，这样的Review会持续N个小时以上，相当的夸张。而且会出现相当多的问题和争论，因为，这就好像，人家都把整个房子盖好了，大家Review时这挑一点那挑一点，有时候触动地基或是承重墙体，需要大动手术，让人返工，这当然会让盖房的人一下就跳起来极力地维护自己的代码，最后还伤了他人的感情。
我们怎么做 Code Review
我带过的项目中，做Code Review这方面大多感觉比较凌乱，也没有什么统一的做法。不过从形式上来看大体可以分为两大类：一类是TM技术经理对项目中成员Team一个一个的做Code Review，或者是团队资深人员来做（姑且就叫个人式吧）。一类是做Code Review Meeting，以会议形式来做Code Review（姑且叫会议式）。
1.个人式
对于个人式，其实在上面如何做Code Review的话题中已经谈到了很多了。包括我们要及时的不定期的每时每刻的去做Code Review，包括我们要按照结构问题，业务逻辑问题，编程素养问题逐一去检查Code等等。很多项目我们也都做了，甚至是都做到了。只是还有不够好的地方，需要深入的地方。具体的方法上面已经讲了，后面我会具体讲讲如何量化和跟踪。而对于PM来说，如何监控Code Review这件事就显得非常重要。
2.会议式
会议式，真正的会议式去做代码评审，如果做到位了效果应该是最好的，最理想的情况是一堆专家（包括技术专家甚至还有业务专家、测试专家等），拿着代码一行一行的去Review。但是这种做法的成本也非常之高，不管是时间成本也好，还是费用成本都相当的昂贵，一般只有在大型尖端项目才会使用，比如航天航空的项目，做Code Review之后的缺陷率是相当的低的。我们是怎么做Code Review Meeting的呢？首先我们会在开会之前，选出典型的案例或者问题一起拿到会上去讨论，多半是分享一些经验和强调一些容易犯错的地方。一般一次会议不会超过2个小时，每周一次会议即可。这样会议的效果比较好，成本也相对较低。因为由于Team中成员的素质参差不齐，所以一起去做代码评审确实效果很差。
我对 Code Review 的一点思考
作为PM我，对Code Review的思考是，我应该如何管理好Code Review？也就是说假设我把Code Review当做一个项目来看，怎样做好这个项目呢？
其实很简单，首先我要有一个正确的、真实的、可执行的计划，然后能在实施Code Review时给予TM或评审人一定的指导，再然后跟踪偏差，分析原因，变更计划。
那麼如何做计划？而且要是正确的、真实的、可执行的。这里我们需要结合一下Project Quality Plan了。可能有的童鞋还不知道，我简单解释一下Project Quality Plan，Project Quality Plan是一个项目质量计划，主要内容有项目交付物以及交付要求，计划达到怎么样的质量目标，要采取怎么样的过程方法，Quality Breakdown各个阶段的质量目标分解等等。通过详细的质量目标分解我们就可以预测各个阶段预计产生的缺陷数是多少。此时我们PM就要思考，有了各个阶段的缺陷数量，我们是不是可以分解一下，那么我们做Code Review的目标是要发现多少缺陷呢？举个例子：假设我们代码的规模是k行，我们目前团队产生缺陷数的基线大概是~ (Bugs/Kloc)，Code Review需要找出8~ (Bugs/Kloc)，也就是*8~=~。这样一来我们总数就有了，也就是说对于k代码行这种规模的项目我们Code Review总共要找到~个缺陷才算达到了比较好的效果。当然如果做到这里还远远不够，我们还要对这个目标进行细化的分解。要分解到模块，分解到人（如果多人Review的话）。分解到模块很好理解，我们把整个系统分解为几个大的模块，或者模块集（相关性大的可以放一起）。然后分析模块的难易度，以及模块将来可能的负责人，然后评估每类模块我们应该找到多少缺陷。可能对于业务复杂或者算法复杂或者负责人水平较低的模块我们需要更多的时间去Review并产出更多的缺陷，反之则少。如下图：
模块规模复杂度PIC缺陷分布（计算）（调整系数）k高中~*.k中中*k中中*k中弱~*.k低弱*有了具体的计划Code Review的时候也就有了指导和参考目标。在执行的时候我们也就可以规划出人合理的力投入分配。做起来相对来说就比较容易了。
最后就是跟踪、偏差分析与变更了，当发现我们与实际计划又严重偏差我们要分析原因，然后做计划变更。比如发现偏差时，我们可以用根因分析，人、机、料、法、环、测。我们哪里做的不够好，如果可以解决，找出主要原因立刻解决即可。如果发现是计划有问题就去变更计划好了。这里就不讨论具体方法了。方法有很多，只要适合自己的项目即可。
其实Code Review的方法还有很多，比如结对编程也是一种很好的形式，特别适合敏捷XP团队，但是因为目前我也没有很好的实践，所以也就没有写到。
最后希望我写的对大家能有一点点的帮助。也欢迎对Code Review有自己见解的朋友能和我一起来探讨这个话题。并欢迎指正我不对的地方。
故障分析 | 从 Insert 并发死锁分析 Insert 加锁源码逻辑
死锁是数据库并发操作中的常见问题，涉及业务关联、机制复杂、类型多样等特点，给分析带来了挑战。本文以MySQL数据库中并发Insert导致死锁为例，通过问题发现、重现、根因分析和解决策略，提供一套科学有效的死锁处理方案。文章首先概述了死锁的基本现象和常见特性，指出死锁触发原因与应用逻辑相关，且涉及多个事务。由于不同数据库的锁实现机制差异，分析死锁问题往往不易。接着，文章详细描述了死锁问题的实例，包括日志提示、innodb status输出和事务执行过程。通过与研发团队的沟通和问题复现，文章进一步分析了事务之间的锁等待和持有状态，提出了问题的具体原因。为解决死锁问题，文章提出了优化唯一索引和调整并发策略的建议，并结合MySQL的锁实现机制，通过源码分析揭示了死锁产生的根本原因。最终，文章总结了避免死锁的关键措施，包括选择适合的隔离级别、减少对Unique索引的依赖，并通过性能数据追踪和源码理解来有效诊断和解决死锁问题。文章旨在为数据库运维人员提供一套实用的死锁处理方法，促进数据库系统稳定性和性能优化。
