ITer_ZC的专栏

这篇对AQS做一个总结。上一篇帖了很多AQS的代码，可以看出AQS的实现思路很简单，就是提供了获取accquire和释放操作release，提供了1. 可中断和不可中断的版本2. 可定时和不可定时的版本3. 独享和共享的版本看过之前实现各种自旋锁系列的同学应该知道，在自旋锁的实现中，获取锁和释放锁操作的逻辑基本如下：自旋锁获取锁操作while 状态不允许获取

关于JVM运行时的内存分布有大量文章写过，没必要重复，在一个博客上看到下面这张图，很好地说清楚了JVM运行时内存各区域的细节，拿来引用一下。下图来自JVM Internals 这篇文章。里面总结了JVM基本的一些知识，很全面，值得看下。

很多人都分不清Major GC, Full GC的概念，事实上我查了下资料，也没有查到非常精确的Major GC和Full GC的概念定义。分不清这两个概念可能就会对这个问题疑惑：Full GC会引起Minor GC吗？经过一系列的查找和对JVM表现的分析，基本可以给Full GC和Major GC下一个定义了，这篇说一说概念和理由。这篇文章Major GCs – Separati

这篇说说GC标记阶段的一些事情，尝试把一些概念说清楚。本人不是研究JVM实现的，如果表述有问题请查看参考资料进一步学习，推荐高级语言虚拟机圈子 ，里面有很多好的文章值得一看。GC最简单的理解就是先把live的对象标记出来，然后把没有标记到的对象清除掉。那么就有几个问题:1. 什么是活的对象？2. 如何标记3. 如何清除先简单说一下清除，清除的方法常见有三种：

在这篇聊聊JVM（六）理解JVM的safepoint 中说了safepoint的基本概念，VM thread在进行GC前，必须要让所有的Java线程阻塞，从而stop the world，开始标记。JVM采用了主动式阻塞的方式，Java线程不是随时都可以进入阻塞，需要运行到特定的点，叫safepoint，在这些点的位置Java线程可以被全部阻塞，整个堆的状态是一个暂时稳定的状态，OopMap指出了

网上已经有了详细的hsdis和jitwatch的教材，比如这篇利用hsdis和JITWatch查看分析HotSpot JIT compiler生成的汇编代码hsdis能够查看Java生成的汇编代码，具体的可以查看上面这篇文章。这里提供一下Mac下的hsdis-amd64.dylib和hsdis-amd64.so文件的下载地址http://pan.baidu.com/s/1i3H

按照惯例新开了一个专栏后要单推一下，推荐一下《聊聊JVM的专栏》，网上关于JVM的文章太多，这个专栏希望能在已有的资料的基础上写出点新意，对一些重要的概念归纳总结，说说自己的观点、理解和实际开发中的经验等等，多多交流

熟悉Linux操作系统的同学应该知道Linux文件系统采用了inode - block的结构来表示和存储文件，inode包含了文件的元数据信息，block存储实际的文件内容。Linux把一切的IO都抽象成文件，那么目录和普通文件一样，也都是文件。每个文件都有一个唯一的inode号。可以用stat命令来查看一个文件的inode信息，比如下面这个文件 stat log.txt可

日志收集在互联网企业尤其是大数据时代是一件非常重要的事情，日志记录着用户行为和系统行为，是一种重要的数据来源。Log4j是Java应用程序使用的最多的一种日志收集工作。目前大量的Java应用程序都使用着Lo4j 1.2.X版本，Log4j 1.X版本饱受诟病的原因是使用了大量的锁，在高并发的情况下影响了系统的性能。这篇简单提供一种思路，说说如何扩展一下Log4j，提升一下Log4j的性能。

safepoint是JVM里面很重要的一个概念，在很多场景下都会看到它，尤其是在GC的时候。这篇讲讲safepoint。本人不是做JVM实现研究的，很多地方只能点到为止，希望能够讲清楚这个概念，具体的细节可以自己去找资料深入研究。safepoint 安全点顾名思义是指一些特定的位置，当线程运行到这些位置时，线程的一些状态可以被确定(the thread's representation

这篇说说如何从JVM的角度来理解线程，可以对Java的线程模型有一个更加深入的理解，对GC的一些细节也会理解地更加深刻。本文基于HotSpot的OpenJDK7实现。我们知道JVM主要是用C++实现的，JVM定义的Thread的类继承结构如下:Class hierarchy - Thread   - NamedThread     - VMThread     -

上一篇总结GC的基础算法，各种GC收集器的基本原理，还是比较粗粒度的概念。这篇会整理一些GC的常见概念，理解了这些概念，相信对GC有更加深入的理解1. 什么时候会触发Minor GC?    Eden区域满了，或者新创建的对象大小 > Eden所剩空间    CMS设置了CMSScavengeBeforeRemark参数，这样在CMS的Remark之前会先做一次Minor GC

在上一篇聊聊高并发（三十三）从一致性(Consistency)的角度理解Java内存模型 我们说了Java内存模型是一个语言级别的内存模型抽象，它屏蔽了底层硬件实现内存一致性需求的差异，提供了对上层的统一的接口来提供保证内存一致性的编程能力。在一致性这个问题域中，各个层面扮演的角色大致如下:1. 一致性模型，定义了各种一致性模型的理论基础2. 硬件层，提供了实现某些一致性模型的硬件能力

可以说并发系统要解决的最核心问题就是一致性的问题，关于一致性的研究已经有几十年了，有大量的理论，算法支持。这篇说说一致性这个主题一些经常提到的概念，理清Java内存模型在其中的位置。一致性问题在单机器单CPU的情况下是最简单的，由于只有一个CPU，所有的读写操作都可以按照全局的时间顺序执行在单机器多CPU的情况下，多CPU并发执行，公用一个内存，一般通过共享内存的方式来处理一致性问

在前几篇将Java内存模型的那些事基本上把这个域底层的概念都解释清楚了，聊聊高并发（三十五）Java内存模型那些事（三）理解内存屏障 这篇分析了在X86平台下，volatile，synchronized, CAS操作都是基于Lock前缀的汇编指令来实现的，关于Lock指令有两个要点:1. lock会锁总线，总线是互斥的，所以lock后面的写操作会写入缓存和内存，可以理解为在lock后面的写缓存

最近时间比较紧张，要写的东西也有很多，只能想到一点写一点。关于GC，网上的资料太多，之前对一个系统调优的时候又回顾了一下，找了几篇广泛流传的资料，大部分都是大同小异，这里总个总结，希望能够做个相对的全集，并写出一些新的点，比如Card Marking（卡片标记）等。首先是大家都要提到的GC的基础算法：标记清除，标记整理，复制，分代。这些算法的第一步都是做的一件事: 标记(Mark)。

最近在准备并发基础的PPT，想到了一些知识点，记录下来以后也可以做个参考。大部分的知识点在之前的博客中都多少涉及到了这里的并发基础指的是单机多处理器的情况下的一些并发问题，不涉及到分布式环境下的并发问题。并发基础主要解决的是可见性，有序性和原子性的问题，让不可控的进程/线程变得可以预测，可以控制行为。Java解决可见性/有序性的主要技术是通过Java内存模型来解决的。J

在聊聊高并发（三十三）从一致性(Consistency)的角度理解Java内存模型 我们说了硬件层提供了满足某些一致性需求的能力，Java内存模型利用了硬件层提供的能力指定了一系列的语法和规则，让Java开发者可以隔绝这种底层的实现专注于并发逻辑的开发。这篇我们来看看硬件层是如何提供这些实现一致性需求的能力的。硬件层提供了一系列的内存屏障 memory barrier / memory

这篇说说如何计算Java对象大小的方法。之前在聊聊高并发（四）Java对象的表示模型和运行时内存表示 这篇中已经说了Java对象的内存表示模型是Oop-Klass模型。普通对象的结构如下，按64位机器的长度计算1. 对象头(_mark)， 8个字节2. Oop指针，如果是32G内存以下的，默认开启对象指针压缩，4个字节3. 数据区4.Padding(内存对齐)，按照8的倍数

最近有一个分布式调用跟踪系统，需要给基于Thrift的RPC调用添加调用链上下文信息，从而可以生成一次调用的调用链。这篇讲讲如何扩展Thrift框架来实现RPC过程中无侵入地添加额外attachment信息的场景。Thrift框架本身提供了很多机制来支持扩展，比如1. 实现TProtocol接口来实现

可配置性是一个好的应用程序的重要指标。我们常常需要实现类似能够运行时修改配置的功能。最近在开发一个中间层的服务程序，最终发布的方式是把代码打成jar包交给调用方使用。这个中间层服务需要一些配置信息，考虑了一下有几个基本的需求：1. 在ja包中提供一个service-defalut.properties配置文件来提供全部的默认配置。这样的好处是尽量减少对调用方的侵入。调用方可以不提供额外的配置。

当自己的程序需要访问微信的HTTP接口时，需要传递access_token作为校验的参数。access_token需要通过APPID和APPSecret秘钥来生成，有效期是7200秒，2小时。access_token最好是做成全局变量共享，然后由一个线程定时去刷新，这样可以减少access_token生成的次数，微信服务器对access_token的生成次数有限制。代码如下，首先是使用Http

ThreadPoolExecutor是Executor执行框架最重要的一个实现类，提供了线程池管理和任务管理是两个最基本的能力。这篇通过分析ThreadPoolExecutor的源码来看看如何设计和实现一个基于生产者消费者模型的执行器。生产者消费者模型生产者消费者模型包含三个角色：生产者，工作队列，消费者。对于ThreadPoolExecutor来说，1. 生产者是任务的提

这篇接着说ExecutorService相关内容。聊聊高并发（三十九）解析java.util.concurrent各个组件（十五） 理解ExecutorService接口的设计这篇说了ExecutorService接口扩展了Executor接口，在执行任务的基础上，提供了执行框架生命周期的管理，任务的异步执行，批量任务的执行的能力。AbstractExecutorService抽象类实现了Exec

上一篇讲了ExecutorService关于任务的异步执行和状态控制的部分，这篇说说关于任务批量执行的部分。ExecutorSerivce中关于批量执行的

ExecutorService最后一块是定时/周期执行任务的接口ScheduledExecutorService。这篇说说ScheduledExecutorService相关的内容。ScheduledExecutorService接口扩展了ExecutorService接口，在ExecutorService的生命周期管理，异步执行任务，批量执行任务的基础上，扩展了定时/周期执行任务的能力。

Executor框架为了更方便使用，提供了Executors这个工厂类，通过一系列的静态工厂方法，可以快速地创建相应的Executor实例。只有一个nThreads参数的newFixedThreadPool方法会创建一个ThreadPoolExecutor，corePoolSize和maximumPoolSize都是nThreads，并且keepAliveTime为0表示不会设置过期时

这篇先从数据的高可用存储说起。ZooKeeper提供了分布式的目录服务，它存储的数据相比一个分布式存储系统来说很少，它主要是用来做分布式协同操作的。但是麻雀虽小，五脏俱全，ZooKeeper也必须要提供数据的高可用存储，对数据进行备份和恢复，以防出现服务器宕机导致数据丢失的情况。    高可用的数据存储有一个比较通用的解决方案，就是数据文件 + 日志文件的方式。比如传统数据库中的数据文件 +

对网络编程来说，最基本的三要素是IO， 协议（编解码），服务器端线程模型。这篇来看看ZooKeeper是如何实现高性能的网络程序。IO模型ZooKeeper默认提供了两种网络IO的实现，一个是Java原生的NIO，一个是基于Netty的IO。先从ServerCnxn这个抽象类看起，它表示一个从客户端到服务器端的网络连接。ServerCnxn实现了Stat服务器端统计接口，Watch

这篇看看ZooKeeper如何管理Session。 Session相关的接口如下： Session: 表示session的实体类,维护sessionId和timeout两个主要状态SessionTracker： Session生命周期管理相关的操作SessionExpier： Session过期的操作public interface SessionTrack

JCU包中除了一系列的同步类之外，就是Executor执行框架相关的类。对于一个执行框架来说，可以分为两部分1. 任务的提交2. 任务的执行。Executor接口设计的目的是专注于任务的执行，和任务的提交解耦。Executor接口封装了任务执行的细节，比如如何使用线程，是否定时执行等等。Executor接口很简单，就一个execute方法。public interface

日志收集是互联网公司的一个重要服务，Flume NG是Apache的顶级项目，是分布式日志收集服务的一个开源实现，具有良好的扩展性，与其他很多开源组件可以无缝集成。搜了一圈发现介绍Flume NG的文章有不少，但是深入分析Flume NG源代码的却没有。最近准备写一个系列分析一下Flume NG的源码。这篇先从基础的配置模块说起。Flume NG支持两种配置模式，一种是基于proper

最近帮朋友搭建一个微信公众号，通过查看微信公众号的开发者手册把基本功能实现了。把一些基本的可以通用的代码贴出来。微信公众号提供了两种模式，一种是直接编辑模式，通过操作页面就能搭建基本的功能，比如自定义菜单功能就很好用。一种是开发者模式，需要写代码来搭建，基于HTTP接口（不完全符合REST风格）。比较麻烦的是两种模式是二选一的关系，使用了开发者模式，就得丢弃一些直接编辑的方便。使用开发者模

Flume NG有4个主要的组件：Event表示在Flume各个Agent之间传递的数据流Source表示从外部源接收Event数据流，然后传递给ChannelChannel表示对从Source传递的Event数据流的临时存储Sink表示从Channel中接收存储的Event数据流，并传递给下游的Source或者终点仓库这篇看一下Event接口表示的数据流。Source,

上一篇说了利用ExecSource从本地日志文件异步的收集日志，这篇说说采用RPC方式同步收集日志的方式。笔者对Thrift比较熟悉，所以用ThriftSource来介绍RPC的日志收集方式。整体的结构图如下：1. ThriftSource包含了一个Thrift Server，以及一个Thrift Service服务的实现。这里的Thrift Service是由ThriftSourcePr

常见的日志收集方式有两种，一种是经由本地日志文件做媒介，异步地发送到远程日志仓库，一种是基于RPC方式的同步日志收集，直接发送到远程日志仓库。这篇讲讲Flume NG如何从本地日志文件中收集日志。ExecSource是用来执行本地shell命令，并把本地日志文件中的数据封装成Event事件流在Flume NG中流动。它的典型配置如下，指定source类型是exec，指定Source下游

上一篇Flume NG源码分析（五）使用ThriftSource通过RPC方式收集日志 介绍了ThriftSource利用Thrfit服务ThriftSourceProtocol来收集日志。这篇说说flume-ng-sdk中提供给应用层序使用的ThriftRPCClient类，它封装了ThriftSourceProtocol服务的客户端并提供了一些优化。先看看ThriftSourceP

前几篇介绍了Flume NG Source组件的基本情况，接下来看看Channel相关的组件，Channel相关组件有：1. Channel2. ChannelSelector3. Interceptor / InterceptorChain4. ChannelProcessor5. Transaction这篇说说ChannelSelector之一的Replicat

上一篇讲了Executor接口的设计，目的是将任务的执行和任务的提交解耦，可以隐藏任务的执行策略。这篇说说ExecutorService接口。它扩展了Executor接口，对Executor的生命周期进行管理，并进行了进一步的扩展。Executor负责执行任务。它的生命周期有3个：运行，关闭和已终止。在运行的任何时刻，有些 任务可能已经完成，有些可能正在运行，有些可能正在队列中等待执行

在上一篇中讲了Flume NG配置模块基本的接口的类，PropertiesConfigurationProvider提供了基于properties配置文件的静态配置的能力，这篇细说一下PollingPropertiesFileConfigurationProvider提供的运行时动态修改配置并生效的能力。要实现动态修改配置文件并生效，主要有两个待实现的功能1. 观察配置文件是否修改