appendReplacement(StringBuffer sb, String replacement)
将当前匹配子串替换为指定字符串，并且将替换后的子串以及其之前到上次匹配子串之后的字符串段添加到一个StringBuffer对象里，而
appendTail(StringBuffer sb) 方法则将最后一次匹配工作后剩余的字符串添加到一个StringBuffer对象里。
例如，有字符串 fatcatfatcatfat，假设既有正则表达式模式为"cat"，第一次匹配后调用appendReplacement(sb, "dog")，那么这时StringBuffer sb的内容为fatdog，也就是fatcat中的cat被替换为dog并且与匹配子串前的内容加到sb里，而第二次匹配后调用 appendReplacement(sb, "dog")，那么sb的内容就变为fatdogfatdog，如果最后再调用一次 appendTail(sb)，那么sb最终的内容将是 fatdogfatdogfat。
介绍注册中心的功能的小节，我们曾经说过，注册中心要有持久化的操作，将一些服务的审核信息放到硬盘上，这样做的原因就是因为我们所有的服务信息都是放在内存里面的，如果注册中心的实例宕掉，或者服务器因为某种原因停止的时候，这样某些服务的审核记录就无法找回，为了避免这样的问题，我们需要做的事情就是把这些服务审核信息定时刷盘，把这些信息保存到硬盘上去，然后每个注册中心服务启动的时候，去硬盘上去恢复这些信息，这样就可以规避这样的问题了
为什么要有引用计数器
Netty里四种主力的ByteBuf，其中UnpooledHeapByteBuf 底下的byte[]能够依赖JVM GC自然回收；而UnpooledDirectByteBuf底下是DirectByteBuffer，如 Java堆外内存扫盲贴 所述，除了等JVM GC，最好也能主动进行回收；而PooledHeapByteBuf 和 PooledDirectByteBuf，则必须要主动将用完的byte[]/ByteBuffer放回池里，否则内存就要爆掉。所以，Netty ByteBuf需要在JVM的GC机制之外，有自己的引用计数器和回收过程。
一下又回到了C的冰冷时代，自己malloc对象要自己free。 但和C时代又不完全一样，内有引用计数器，外有JVM的GC，情况更为复杂。
并发编程实践中，this引用逃逸（"this"escape）是指对象还没有构造完成，它的this引用就被发布出去了。这是危及到线程安全的，因为其他线程有可能通过这个逸出的引用访问到“初始化了一半”的对象(partially-constructed object)。这样就会出现某些线程中看到该对象的状态是没初始化完的状态，而在另外一些线程看到的却是已经初始化完的状态，这种不一致性是不确定的，程序也会因此而产生一些无法预知的并发错误。在说明并发编程中如何避免this引用逸出之前，我们先看看一个对象是如何产生this引用逸出的。
static是java中非常重要的一个关键字，而且它的用法也很丰富，主要有四种用法：
slf4j与log4j联合使用
slf4j是什么？slf4j只是定义了一组日志接口，但并未提供任何实现，既然这样，为什么要用slf4j呢？log4j不是已经满足要求了吗？
是的，log4j满足了要求，但是，日志框架并不只有log4j一个，你喜欢用log4j，有的人可能更喜欢logback，有的人甚至用jdk自带的日志框架，这种情况下，如果你要依赖别人的jar，整个系统就用了两个日志框架，如果你依赖10个jar，每个jar用的日志框架都不同，岂不是一个工程用了10个日志框架，那就乱了！
MyBatis 的配置文件 Configuration 中有相关属性，设属性即可，不用再放一个 log4j.properties 文件。
<configuration>
<settings>
……
<setting name="logImpl" value="STDOUT_LOGGING"/>
</settings>
</configuration>
配置完成后，在 IDE 的控制台下可以看到程序运行过程中的 SQL，参数，返回结果等。
子类调用继承来的父类的方法，输出this，显示this是指向子类实例的指针。
但是输出this.name，却输出的是父类的成员变量，而没有使用子类中定义的同名变量（讲道理不应该就近选择子类的name变量？）