1. SpringBoot内置生命周期事件详解 SpringBoot源码(十)
SpringBoot中文注释项目Github地址：扒派族
https://github.com/yuanmabiji/spring-boot-2.1.0.RELEASE
本篇接 SpringBoot事件监听机制源码分析(上) SpringBoot源码(九)
温故而知新，我们来简单回顾一下上篇的内容，上一篇我们分析了 SpringBoot启动时广播生命周期事件的原理羡汪 ，现将关键步骤再浓缩总结下：
上篇文章的侧重点是分析了SpringBoot启动时广播生命周期事件的原理，此篇文章我们再来详细分析SpringBoot内置的7种生命周期事件的源码。
分析SpringBoot的生命周期事件，我们先来看一张类结构图：
由上图可以看到事件类之间的关系：
EventObject 类是JDK的事件基类，可以说是所有Java事件类的基本，即所有的Java事件类都直接或间接继承于该类，源码如下：
可以看到 EventObject 类只有一个属性 source ，这个属性是用来记录最初事件是发生在哪个类，举个栗子，比如在SpringBoot启动过程中会发射 ApplicationStartingEvent 事件，而这个事件最初是在 SpringApplication 类中发射的，因此 source 就是 SpringApplication 对象。
ApplicationEvent 继承了DK的事件基类 EventObject 类，是Spring的事件基类，被所有Spring的具体事件类继承，源码如下：
可以看到 ApplicationEvent 有且仅有一个属性 timestamp ，该属性是用来记录事件发生的时间。
SpringApplicationEvent 类继承了Spring的事件基类 ApplicationEvent ，是所有SpringBoot内置生命周期事件的父类，源码如下：
可以看到 SpringApplicationEvent 有且仅有一个属性 args ，该属性就是SpringBoot启动时的命令行参数即标注 @SpringBootApplication 启动类中 main 函数的参数。
接下来我们再来看一下 SpringBoot 内置生命周期事件即 SpringApplicationEvent 的具体子类们。
SpringBoot开始启动时便会发布 ApplicationStartingEvent 事件，其发布时机在环境变量Environment或容器ApplicationContext创建前但在注册 ApplicationListener 具体监听器之后，标志标志 SpringApplication 开始启动。
可以看到 事件多了一个 environment 属性，我们不妨想一下，多了 environment 属性的作用是啥？
答案就是 事件的 environment 属性作用是利用事件发布订阅机制，相应监听器们可以从 事件中取出 environment 变量，然后我们可以为 environment 属性增加属性值或读出 environment 变量中的值。
当SpringApplication已经开始启动且环境变量 Environment 已经创建后，并且为环境变量 Environment 配置了命令行和 Servlet 等类型的环春弊境变量后，此时会发布 事件。
监听 事件的第一个监听器是 ConfigFileApplicationListener ，因为是 ConfigFileApplicationListener 监听器还要为环境变量 Environment 增加 application.properties 配置文件中的环境变量；此后还有一些也是监听 事件的其他监听器监听到此事件时，此时可以说环境变量 Environment 几乎已经完全准备好了。
可以看到 事件多了个 类型的 context 属性， context 属性的作用同样是为了相应监听器可以拿到这个 context 属性执行一些逻辑，具体作用将在 3.4.4 详述。
事件在 ApplicationContext 容器创建后，且为 ApplicationContext 容器设置了 environment 变量和执行了 的初始化方法后但在bean定义加载前触发，标志ApplicationContext已经初始化完毕。
同样可以看到 ApplicationPreparedEvent 事件多了个 类型的 context 属性，多了 context 属性的作用是能让监听该事件的监听器们能拿到 context 属性，监听器拿到 context 属性一般有如下作用：
ApplicationPreparedEvent 事件在 ApplicationContext 容器已经完全准备好时但在容器刷新前触发，在这个阶段 bean 定义已经加载完毕还有 environment 已经准备好可以用了。
ApplicationStartedEvent 事件将在容器刷新后但 ApplicationRunner 和 CommandLineRunner 的 run 方法执行前触发，标志 Spring 容器已经刷新，此时容器已经准备完毕了。
ApplicationReadyEvent 事件在调用完 ApplicationRunner 和 CommandLineRunner 的 run 方法后触发，此时标志 SpringApplication 已经正在运行。
可以看到 ApplicationFailedEvent 事件除了多了一个 context 属性外，还多了一个 Throwable 类型的 exception 属性用来记录SpringBoot启动失败时的异常。
ApplicationFailedEvent 事件在SpringBoot启动失败时触发，标志SpringBoot启动失败。
此篇文章相对简单，对SpringBoot内置的7种生命周期事件进行了详细分析。我们还是引用上篇文章的一张图来回顾一下这些生命周期事件及其用途：
由于有一些小伙伴们建议之前有些源码分析文章太长，导致耐心不够，看不下去，因此，之后的源码分析文章如果太长的话，笔者将会考虑拆分为几篇文章，这样就比较短小了，比较容易看完，嘿嘿。
【源码笔记】Github地址：
https://github.com/yuanmabiji/Java-SourceCode-Blogs
点赞搞起来，嘿嘿嘿！
公众号【 源码笔记 】专注于Java后端系列框架的源码分析。
2. 如何正确地查看源代码
一。先把源代码安装起来编译起来，结合它的文档和手册，熟悉其功能和它的应用方式。如果遇到的是英文文档，那么首先恭喜你，如果硬着头皮看下来，不仅能在国内开此系统或框架的先河，而且能让你阅读英文的水平大幅提升。
二。浏览源代码的目录结构，了解各个目录的功能。从整体上观察这个工程是有哪些模块组成的，最好能画一画图。
三。经过以上两步后你对这份源代码有了一个初步的了解了，现在开始分析它的源码吧。这一步我们开始分析源代码框架。例如入口方式是单入口还是多入口，页面之间的调用规则，能根据规则找出某个功能用到的页面。
四。熟悉源代码的代码写作风格，例如缩进方式，排版格式，变量命名，函数命名等。
五。熟悉一下源代码用到的数据库和表，可以参考它的技术支持文档。
六。经过以上几步相信已经对源代码有了更深刻的了解，不过这种了解还只是表面的，下来我们从7个方面具体的去分析它吧：
1.入口构造以及页面调用方式的具体实现，如果阅读时看到工具类和工具函数，尽量去熟悉一下。这一步的分析可以学习到源代码的系统架构方式。
2.分析源代码用到的工具类和工具函数，这样可以学到很多程序编写技巧。可以提升自己编程功力。
3.结合一些安全规则，研究这个源代码是怎样实现安全方面的设计的。这样可以提高自己在安全方面的意识和功力。
4.如果有模板引擎的话，研究一下源代码的模板引擎。大致从实现方式，效率，易用性等几个方面去考虑。
5.研究系统的各个功能模块，这样既能学习编程技巧还能打开自己的编程思路，下次遇到类似的东东就心里有谱了。
6.研究系统所用到设计模式，一样的功能实现，用到的设计模式可能相差很多，对比我们之前所作的东东分析设计模式，是提升我们驾驭代码的不二法门。
7.研究源代码对访问压力，执行效率，系统效率，数据库查询的优化。
七。做笔记，把这个开源代码实现的功能，实现方式、设计框架、模块组织、以及代码技巧等记录下来。边记录边总结整理，对学习的东西更容易消化吸收。
八。实践是检验真理的唯一标准，修改一些比较简单地功能，或者写一些简单的sample，并且调试出来，这样才能做到更加理解代码。同时框架性的源代码里一般都有自带的实例，修改使用这些实例，可以快速了解框架的使用。
3. Android源码解析Window系列第（一）篇---Window的基本认识和Activity的加载流程
您可能听说过View ,ViewManager,Window,PhoneWindow,WindowManager,WindowManagerService,可是你知道这几个类是什么关系，干嘛用的。概括的来说，View是放在Window中的，Window是一个抽象类，它的具体实现是PhoneWindow，PhoneWindow还有个内部类DecorView，WindowManager是一个interface，继承自ViewManager，它是外界访问Window的入口，，提供了add/remove/updata的方法操作View，WindowManager与WindowManagerSerice是个跨进程的过程，WindowManagerService的职责是对系统中的所有窗口进行管理。如果您不太清楚，建议往下看，否则就不要看了。
Android系统的Window有很多种，大体上来说，Framework定义了三种窗口类型；
这就是Framework定义了三种窗口类型，这三种类型定义在WindowManager的内部类LayoutParams中，WindowManager讲这三种类型 进行了细化，把每一种类型都用一个int常量来表示，这些常量代表窗口所在的层，WindowManagerService在进行窗口叠加的时候，会按照常量的大小分配不同的层，常量值越大，代表位置越靠上面， 所以我们可以猜想一下，应用程序Window的层值常量要小于子Window的层值常量，子Window的层值常量要小于系统Window的层值常量。 Window的层级关系如下所示。
上面说了Window分为三种，用Window的type区分，在搞清楚Window的创建之前，我们需要知道怎么去描述一个Window，我们就把Window当做一个实体类，给我的感觉，它必须要下面几个字段。
实际上WindowManager.LayoutParams对Window有很详细的定义。
提取几个重要的参数
Window是一个是一个抽象的概念，千万不要认为我们所看到的就是Window,我们平时所看到的是视图，每一个Window都对应着一个View，View和Window通过ViewRootImpl来建立联系。有了View，Window的存在意义在哪里呢，因为View不能单独存在，它必须依附着Window，所以有视图的地方就有Window,比如Activity,一个Dialog,一个PopWindow,一个菜单，一个Toast等等。
通过上面我们知道视图和Window的关系，那么有一个问题，是先有视图，还是先有Window。这个答案只有在源码中找了。应用程序的入口类是ActivityThread，在ActivityThread中有performLaunchActivity来启动Activity，这个performLaunchActivity方法内部会创建一个Activity。
如果activity不为null,就会调用attach,在attach方法中通过PolicyManager创建了Window对象，并且给Window设置了回调接口。
PolicyManager的实现类是Policy
这样Window就创建出来了， 所以先有Window，后有视图，视图依赖Window存在 ，再说一说视图（Activity）为Window设置的回调接口。
Activity实现了这个回调接口，当Window的状态发生变化的时候，就会回调Activity中实现的这些接口，有些回调接口我们还是熟悉的，dispatchTouchEvent，onAttachedToWindow，onDetachedFromWindow等。
下面分析view是如何附属到window上的，通过上面可以看到，在attach之后就要执行callActivityOnCreate，在onCreate中我们会调用setContentView方法。
getWindow获取了Window对象，Window的具体实现类是PhoneWindow,所以要看PhoneWindow的setContentView方法。
这里涉及到一个mContentParent变量，他是一个DecorView的一部分，DecorView是PhoneWindow的一个内部类，我先介绍一下关于DecorView的知识。
DecorView是Activity的顶级VIew，DecorView继承自FrameLayout,在DecorView中有上下两个部分，上面是标题栏，下面是内容栏，我们通过PhoneWindow的setContentView所设置的布局文件是加到内容栏（mContentParent）里面的，View层的事件都是先经过DecorView在传递给我们的View的。
OK在回到setContentView的源码分析，我们可以得到Activity的Window创建需要三步。
- 1、 如果没有DecorView，在installDecor中创建DecorView。
- 2、将View添加到decorview中的mContentParent中。
- 3、回调Activity的onContentChanged接口。
先看看第一步，installDecor的源码
installDecor中调用了generateDecor，继续看
直接给new一个DecorView，有了DecorView之后，就可以加载具体的布局文件到DecorView中了，具体的布局文件和系统和主题有关系。
在看第二步，将View添加到decorview中的mContentParent中。
直接将Activity视图加到DecorView的mContentParent中，最后一步，回调Activity的onContentChanged接口。在Activity中寻找onContentChanged方法，它是个空实现，我们可以在子Activity中处理。
到此DecorView被创建完毕，我们一开始从Thread中的handleLaunchActivity方法开始分析，首先加载Activity的字节码文件，利用反射的方式创建一个Activity对象，调用Activity对象的attach方法，在attach方法中，创建系统需要的Window并为设置回调，这个回调定义在Window之中，由Activity实现，当Window的状态发生变化的时候，就会回调Activity实现的这些回调方法。调用attach方法之后，Window被创建完成，这时候需要关联我们的视图，在handleLaunchActivity中的attach执行之后就要执行handleLaunchActivity中的callActivityOnCreate，在onCreate中我们会调用setContentView方法。通过setContentView，创建了Activity的顶级View---DecorView,DecorView的内容栏（mContentParent）用来显示我们的布局。 这个是我们上面分析得到了一个大致流程，走到这里，这只是添加的过程，还要有一个显示的过程，显示的过程就要调用handleLaunchActivity中的handleResumeActivity方法了。最后会调用makeVisible方法。
这里面首先拿到WindowManager对象，用tWindowManager 的父接口ViewManager接收，ViewManager可以
最后调用 mDecor.setVisibility(View.VISIBLE)设置mDecor可见。到此，我们终于明白一个Activity是怎么显示在我们的面前了。
参考链接：
http://blog.csdn.net/feiclear_up/article/details/49201357
4. UCOS----时钟节拍源码分析
时钟节拍类似于人体心脏的跳动，人体依赖心脏的跳动将血液输入身体各个部位，支撑生命活动。时钟节拍的是操作系统的时基，操作系统依赖于时钟节拍推动 CPU 去执行指令。
时钟节拍是系统以固定的频率产生中断（时基中断），并在中断处理与时间相关的事件，推动所有任务向前运行。时钟节拍需要依赖于硬件定时器，STM32 通常使用 systick 时钟作为 MCU 的内核定时器。
根据系统时钟的初始化，在系统计数达到后，产生时钟中断，并调用中断处理函数 OS_CPU_SysTickHandler 。
在 OS_CPU_SysTickHandler 函数中调用了 UCOS 的时间片处理函数 OSTimeTick ，对系统的时间片进行处理。
在 OSTimeTick 函数中给时基任务、定时器任务都发送了信号量。这里先介绍时基任务。时基任务是在 OS 初始化函数 void OSInit (OS_ERR *p_err) 中创建。
本章阐述了时钟节拍的工作原理，看似微小却是整个 uC/OS 系统的命脉。时钟节拍的运行依赖于 CPU 的定时器， STM32 专门为此量身定制了 SysTick 时钟。每个时钟节拍到来时，时基任务就会执行，节拍任务的重点是更新节拍任务列表。在节拍列表中，存放的均是与时间事件（如延时或超时）相关的任务。如果任务到期，则需要更新响应的任务状态。
5. 如何分析网站源码
分析网站源码可以从以下同个方面
第一,网站采用的技术,是php还是asp,通常php好于asp
第二,网站布局结构是用的div/css还是tabel通常div布局更有利网站收录
第三,网站的源码是否支持二次开发,书写是否规范.只要看代码有没有加密,有没有注释,易不易看懂
第四,网站源码是否原创,是否有版权问题.如果你是要用它建站,这个还是要注意下了.免得吃官司
第五,源码的安全性,可以用360网站网站在线安全检测来检查一下.
综上所述就是分析网站的几个点了,打了这么多字希望采纳
6. 服务器程序源代码分析之二：php-fpm
php作为排名top2 互联网开发工具，非常流行，可以参考：中国最大的25个网站采用技术选型方案
php这个名称实际上有两层含义
直接定义：
php-fpm从php5.3.3开始已经进入到php源代码包，之前是作为patch存在的
很少人会去读php本身源代码，我6年前解决php内存泄露问题的时候做了些研究,最近再查看了一番，发现php的开发者很有诚意，这是一款非常出色的服务器软件，支持如下
在linux服务器上，如果不设置 events.mechanism ,那么默认就是采用epoll，所以
php-fpm的IO模型&并发处理能力和nginx是完全一致
nginx以性能卓越闻名，大部分程序员都认为php效率低下，看了源代码，才知道这是传奇啊
在高性能部署的时候，大家往往会针对性的优化nginx 。我自己之前部署php程序也犯了错误，8G内存的server，php-fpm的max children都会设置128+，现在看来太多了，参考nginx的部署:
php-fpm配置为 3倍 cpu core number就可以了
php-fpm稳定性比nginx稍差 这是因为php-fpm内置了一个php解析器,php-fpm进程就和php程序捆绑了，如果php脚本写得不好，有死循环或者阻塞在某个远端资源上，会拖累加载它的php-fpm进程
而nginx和后端应用服务器之间通过网络连接，可以设置timeout，不容易堵死的
php-fpm的fastcgi是短连接 我原以为是长连接的，看了代码才知道也是短连接，处理一个request就关闭掉
php-fpm接口采用fastcgi 非常遗憾，php-fpm和fastcgi完全绑定了，无法独立使用 。只能部署在支持http-fcgi协议转换程序背后(nginx）。其实可以考虑在php-fpm代码包里面引入http协议支持，这样php-fpm可以独立运行，让nodejs无话可说
php-fpm等同于OpenResty OpenResty是一个国人开发的nginx模块，就是在nginx引入lua解释器. 实际上，它和php-fpm的唯一差别就是一个采用php语法，一个用lua，所以OpenResty要作为nginx增强包使用还可以，要选择它作为一个主要编程工具，没有任何必要
从架构上来说，php-fpm已经做到最好，超过大多数 python部署工具，我再也不黑它了
7. Netty源码分析（七） PoolChunk
在分析源码之前，我们先来了解一下Netty的内存管理机制。我们知道，jvm是自动管理内存的，这带来了一些好处，在分配内存的时候可以方便管理，也带来了一些问题。jvm每次分配内存的时候，都是先要去堆上申请内存空间进行分配，这就带来了很大的性能上的开销。当然，也可以使用堆外内存，Netty就用了堆外内存，但是内存的申请和释放，依然需要性能的开销。所以Netty实现了内存池来管理内存的申请和使用，提高了内存使用的效率。
PoolChunk就是Netty的内存管理的一种实现。Netty一次向系统申请16M的连续内存空间，这块内存通过PoolChunk对象包装，为了更细粒度的管理它，进一步的把这16M内存分成了2048个页（pageSize=8k）。页作为Netty内存管理的最基本的单位 ，所有的内存分配首先必须申请一块空闲页。Ps: 这里可能有一个疑问，如果申请1Byte的空间就分配一个页是不是太浪费空间，在Netty中Page还会被细化用于专门处理小于4096Byte的空间申请 那么这些Page需要通过某种数据结构跟算法管理起来。
先来看看PoolChunk有哪些属性
Netty采用完全二叉树进行管理，树中每个叶子节点表示一个Page，即树高为12，中间节点表示页节点的持有者。有了上面的数据结构，那么页的申请跟释放就非常简单了，只需要从根节点一路遍历找到可用的节点即可。主要来看看PoolChunk是怎么分配内存的。
Netty的内存按大小分为tiny,small,normal,而类型上可以分为PoolChunk,PoolSubpage，小于4096大小的内存就被分成PoolSubpage。Netty就是这样实现了对内存的管理。
PoolChunk就分析到这里了。