Kafka消费者客户端从Kafka cluster中读取消息并处理。Kafka消费者可以手动绑定自己到某个topic的某些partition上或者通过subscribe方法监听某个topic自动绑定。

本文是kafka源码分析第4篇，介绍了Kafka broker上对于produce生产者生产消息的处理。

Kafka broker上对于produce生产者生产消息的处理。

本文是kafka源码分析第3篇，介绍了Kafka Producer处理机制。

KafkaProducer是异步的，调用send方法后，kafka并没有立即发送给broker，而是先放在buffer缓冲池中就立即返回，后台的IO线程来负责把消息记录转换成请求发送给kafka集群。

本文是Kafka 源码分析的第二篇，这里我们直接跑到最底层，看看kafka的网络层处理是怎么处理的。

从kafka也算有两年了，用它做了不少项目，但是之前对它的认识也仅仅停留在一些从其他地方听到的概念和官方文档的documentation上在遇到一些问题时往往不知道其原理只能按照道听途说的概念来理解。

disruptor经过几年的发展，似乎已经成为性能优化的大杀器，几乎每个想优化性能的项目宣称自己用上了disruptor，性能都会呈现质的跃进。毕竟，最好的例子就是LMAX自己的架构设计，支撑了600w/s的吞吐。

本文基于JUnit4.12，将从JUnit的运行流程，Match验证，两个方面，来对JUnit的源码进行整体的分析。

本文将介绍一下 Tomcat 请求处理流程。

这个题目命的其实是很大的，写的时候还是很忐忑的，但我尽可能把这个过程描述清楚。因为这是读过源码以后写的总结，在写的过程中可能会忽略一些前提条件，如果有哪些比较突兀就出现，或不好理解的地方可以给我提 Issue，我会尽快补充修订相关内容。

Spring 最重要的概念是 IOC 和 AOP，本篇文章其实就是要带领大家来分析下 Spring 的 IOC 容器。既然大家平时都要用到 Spring，怎么可以不好好了解 Spring 呢？

之前重点分析的是finishBeanFactoryInitialization方法，这个方法完成了所有非懒加载的单例Bean的初始化。今天我回头重看了一下refresh()方法，发现前面有一些方法还是忽略了没有去特别在意，其实他们都是Spring整个启动流程中的重要组成部分，下面就来分析一下finishBeanFactoryInitialization方法前面的一些方法。

上文分析了单例的Bean初始化流程，并跟踪代码进入了主流程，看到了Bean是如何被实例化出来的。下面继续分析初始化一个Bean的流程，不太重要的流程就跳过了。

本文针对preInstantiateSingletons进行分析，解读一下Spring是如何初始化Bean实例对象出来的。

很多朋友可能想看Spring源码，但是不知道应当如何入手去看，这个可以理解：Java开发者通常从事的都是Java Web的工作，对于程序员来说，一个Web项目用到Spring，只是配置一下配置文件而已，Spring的加载过程相对是不太透明的，不太好去找加载的代码入口。

想对spring框架进行深入的学习一下，看看源代码，提升和沉淀下自己

虽然说解释执行模式是逐字逐句翻译给目标平台运行的，但这样的过程未免太过缓慢，如果能把字节码说的话做成纸条，运行时只要把对应的纸条交给目标平台就可以了，这样，执行速度就会明显提升。

future是一个经常在多线程环境下使用的Runnable，使用它的好处有两个：线程执行结果带有返回值；提供了一个线程超时的功能，超过超时时间抛出异常后返回。文本对FutureTask源码进行了深入地解析。