几乎每个Java程序员都清楚知道Java的异常和错误机制，无论是在面试过程中，还是在学习中，你看到Exception，无非就是了解一下继承关系、子类、和Error的关系等等。当然这些知识点是基础，那么在实践中，用到了吗？你确定你使用Exception时没有偷懒？我的经验告诉我，良好的使用Exception能让你的程序bug更少，或者至少能保证你的程序更容易被理解和跟踪。

        先回到老的知识点吧——Java的异常机制，我们知道Java里的异常是完全继承Throwable的，正如java doc里注释的，无论你throw的还是JVM throw的，抑或是你想catch的，都必须继承Throwable。我这里帮助大家纠正的第一个点就是：java.lang.Throwable是一个class，不是一个interface，千万别被名字欺骗。优秀的程序员有好的命名习惯，当Java程序员默认认为带有-able后缀的都该是接口时， Josh Bloch给大家上了一课——Throwable就是类。回到正题，Throwable有两大子类，一个是java.lang.Error，一个是java.lang.Excpetion，Error是错误，一般多用于系统异常和底层错误，Error抛出就会导致程序终止；而Exception是异常，有程序引起，又分为受检的checked和非受检的unchecked（不知道哪本书这么翻译的来着），受检的异常是普通异常，就是你需要catch的来打日志或者补救的（这种做法叫吞掉异常），非受检的多数是RuntimeException，就是运行时异常，这类异常不建议catch，因为这个是程序bug，需要被人发现，所以建议抛出引起程序终止。Blah~blah~ 这些都是老生常谈的话题，需要深入的点是有几个：

        第一，Error是建议到系统级别的错误的，包括虚拟机的，我们常见的就是java.lang.VirtualMachineError，这是一个JVM级别的抽象Error，如果你觉得没见过？那么不用奇怪，它的两个儿子你肯定见过：OutOfMemoryError和StackOverflowError。Error其实真没好说的，一般情况不建议捕获，程序员也用的较少，但是你看很多基础框架或者系统软件，都是有自定义Error的，所以当你的工作层次或者范围你能确定比较底层时，其实是可以自定义一些Error来控制程序的错误的。我这样说可能也不是很好理解，换个简单的话：你的架构设计中需要考虑到异常的处理，那么首先要对异常定级别，如果有可能有偏底层的异常时，或者是本不该出现且不建议用户（多数是依赖你的库进行开发的其他程序员）捕获时，定义为Error是个不错的选择。当然也不是说做上层开发的程序员就不能使用Error，只要你设计合理，你可以在必要时抛出Error来终止程序——比如提醒你的老板再不加薪就Error到死：）

        第二，Exception分两类这事几乎人人皆知，受检的异常往往是web后端开发或者服务开发自定义的业务异常比如BizServiceException或者常见的DAOException，这些异常在开发定义时总是直接extends Exception，而忽视了究竟这些异常我们对它们的期望是什么，这里我想强调一点，我们在业务系统架构中考虑到异常机制，自定义的异常不是为了有异常而定义异常，一定对它本身是有期望的。我们对异常的一个基本期望是异常究竟该被谁捕获，如果被你的服务下游捕获，那么这必须是一个受检的异常，如果是系统自身需要，那么这个我个人认为是分阶段设计的，在初期，也就是未发布状态，这些Exception应该总是被抛出的，因为这样可以快速的让测试和质量控制人员发现系统崩溃的点。在发布阶段，异常可能需要被内部消化，这时受检异常就要提供给业务系统，让业务开发自行捕获异常。当然，好的系统架构可能会把Exception作为一个内部可见外部不可见的内容，而基于此完全封装一套error code对外，这应该算是比较友好的做法了，也是很多API设计时的标准规范。毕竟对外部透明，不要让用户看到你的Exception，这是非常友好的做法。

        第三，关于catch，就针对上面的第二点讲，吞异常这事不是没人干过，我们往往担心系统错误而一个try catch 捕获所有Exception，有的甚至不够，还升一级，捕获Throwable，这应该是最糟糕的代码设计（但不幸的是在我现在开发的系统和曾经开发过的业务系统中，这类代码非常普遍）。开发人员不应该因为时间紧、赶进度等接口而忽视Exception，就拿最上层的业务开发举例，开发可能会调用各类服务、访问数据库、访问缓存和文件系统等等，而这些服务必然包含了各种异常，而catch一个Exception，试图通过吞噬异常保护系统或者页面正常访问，而打日志到后台，通过分析日志来偷偷的解决bug……说起来真是汗毛倒竖。我的观点：如果有错误，那么让它尽早暴露出来，我们应该通过尽量多的测试和优化来避免错误，而不是偷偷的隐藏。事实也证明，日志里大量的NPE或者其他RuntimeException存在，但是无人问津，“系统不是好好的吗？”，“页面不是没问题吗”这样的说辞可以让开发看起来毫无责任，但是这为系统长期的维护和后续的扩展都带来了无尽的烦恼和坑。

         综上，我个人的经验告诉我几点对待Exception的方法：

        1，花时间了解涉及到的每个服务和方法所可能抛出的异常。事实往往是理解异常的关系和机制其实不花时间，了解后再开发，你会比别人知道更多的异常点，这能保证你程序的健壮性；

        2，无论你在服务开发还是服务使用层级，都要尝试或者想到封装异常，提供友好错误设计的方案，最简单的是自定义一个业务Exception来封装。

        3，不要在你的方法开始try，结束时catch，这防御性太强了，很美品位。

        4，前三点可能都是错的，因为我自己也没有完全实践：）

2，从逻辑存储结构到实际的物理存储结构要经历一个fold过程，所有的columnFamily下的内容被有序的合并，因为HBase把一个ColumnFamily存储为一个StoreFile。

3，把HBase的查询等价为一个逐层过滤的行为，那么在设计存储时就应该明白，使设计越趋向单一的keyvalue性能会越好；如果是因为复杂的业务逻辑导致查询需要确定rowkey、column、timestamp，甚至更夸张的是用到了HBase的Filter在server端做value的处理，那么整个性能会非常低。

4，因此在表结构设计时，HBase里有tall narrow和flat wide两种设计模式，前者行多列少，整个表结构高且窄；后者行少列多，表结构平且宽；但是由于HBase只能在行的边界做split，因此如果选择flat wide的结构，那么在特殊行变的超级大（超过file或region的上限）时，那么这种行为会导致compaction，而这样做是要把row读内存的~~因此，强烈推荐使用tall narrow模式设计表结构，这样结构更趋近于keyvalue，性能更好。

5，一种优雅的行设计叫做partial row scan，我们一般rowkey会设计为<key1>-<key2>-<key3>...，每个key都是查询条件，中间用某种分隔符分开，对于只想查key1的所有这样的情况，在不使用filter的情况下（更高性能），我们可以为每个key设定一个起始和结束的值，比如key1作为开始，key1+1作为结束，这样scan的时候可以通过设定start row和stop row就能查到所有的key1的value，同理迭代，每个子key都可以这样被设计到rowkey中。

6，对于分页查询，推荐的设计方式也不是利用filter，而是在scan中通过offset和limit的设定来模拟类似RDBMS的分页。具体过程就是首先定位start row，接着跳过offset行，读取limit行，最后关闭scan，整个流程结束。

7，对于带有时间范围的查询，一种设计是把时间放到一个key的位置，这样设计有个弊端就是查询时一定要先知道查询哪个维度的时间范围值，而不能直接通过时间查询所有维度的值；另一种设计是把timestamp放到前面，同时利用hashcode或者MD5这样的形式将其打散，这样对于实时的时序数据，因为将其打散导致自动分到其他region可以提供更好的并发写优势。

8，对于读写的平衡，下面这张图更好的说明了key的设计：salting等价于hash，promoted等价于在key中加入其他维度，而random就是MD这样的形式了。

9，还有一种高级的设计方式是利用column来当做RDBMS类似二级索引的应用设计，rowkey的存储达到一定程度后，利用column的有序，完成类似索引的设计，比如，一个CF叫做data存放数据本身，ColumnQualifier是一个MD5形式的index，而value是实际的数据；再建一个CF叫做index存储刚才的MD5，这个index的CF的ColumnQualifier是真正的索引字段（比如名字或者任意的表字段，这样可以允许多个），而value是这个索引字段的MD5。每次查询时就可以先在index里找到这个索引（查询条件不同，选择的索引字段不同），然后利用这个索引到data里找到数据，两次查询实现真正的复杂条件业务查询。

10，实现二级索引还有其他途径，比如：1，客户端控制，即一次读取将所有数据取回，在客户端做各种过滤操作，优点自然是控制力比较强，但是缺点在性能和一致性的保证上；2，Indexed-Transactional HBase，这是个开源项目，扩展了HBase，在客户端和服务端加入了扩展实现了事务和二级索引；3，Indexed-HBase；4，Coprocessor。

11，HBase集成搜索的方式有多种：1，客户端控制，同上；2，Lucene；3，HBasene，4，Coprocessor。

12，HBase集成事务的方式：1，ITHBase；2，ZooKeeper，通过分布式锁。

13，timestamp虽然叫这个名字，但是完全可以存放任何内容来形成用户自定义的版本信息。

2，一个列簇CF的所有列存储在一个HFile里

3，CF要在建表时定义，少变化，更不要建太多

4，version和timestamp是对应的，每个cell有不同的版本，就说明是在不同的timestamp存储的，如果重复的timestamp，那么就说明是一个版本

5，定位一个数据，需要rowkey，column和timestamp，即SortedMap<RowKey,List<SortedMap<Column,List<Value,Timestamp>>>>

6，初始一个region，之后自动sharding，一台server大概10-1000个region，每个region大小为1-2GB

7，每一个HFile有一个block index，可以只用一次disk seek完成查询

8，数据更新时要写commit log即常说的WAL——write-ahead-log，每次操作都会记录在内存memstore，当memstore满了以后自动flush到HFile的disk，在做flush时，reader和writer不被阻塞，可以继续服务（这是因为，flush做的是一个滚动操作，老的满的数据flush到磁盘，而完成后的新的空的memstore继续服务，因为memstore已经是按key的顺序排好的，所以不需要额外操作，只要写和flush就行）

9，删除操作是逻辑的，因为存储文件不可变，所以会放置一个删除标记到每个键值对

10，通过compaction将小的hfile合并为大的，compaction有两种类型：minor和major，前者通过多路归并完成多个小文件到少量大文件的合并；后者重写整个CF到一个新的文件，在做compaction的时候可以把之前标记过delete的kv pair放弃，即不写到新的文件

11，HBase由客户端库，一台master server和多台region server组成，master负责regions的负载均衡，master不存储数据，只做调度

12，扫表scan是线性时间的，查询是对数时间的，而极端情况的查询是常数时间的（使用bloom filter）

13，在put时，要注意flush的时间，没有flush的数据是不会被get到的，从源码可以了解到，flush有两种情况，一是显示调用flushCommits()；另外就是到了client端的writebuffer上限触发，hbase默认client的writebuffer size是2M，可以通过配置去修改

14，HBase的client里，caching针对行模式（返回多少行），而batching针对列模式（返回多少列），都是在scan时提高效率（减少RPC）的方法

15，用HBase的接口时，通过Filter的使用可以减少网络传输的数据量，从而减轻在客户端使用的时间成本，get或scan你想要的东西，不要的东西直接在server通过filter过滤到

16，在重用Configuration时，要记得每次都会增加一个引用数，因此在使用完后最好调用close方法将connection释放掉

17，HBase的block size和hdfs的block size是不一样的，前者是指处理block操作时的数据大小，默认是64KB，而后者是用来分布式存储文件，默认大小是64MB

18，RDBMS和Hbase的区别：存储结构b树或b+树，Hbase采用类似LSM树的做法（Log-Structured Merge Trees)，LSMT的简单过程描述是，数据首先被顺序存储到一个log file里，在写满后将这些数据更新到in memory store，然后flush有序key value pair到磁盘，生成一个文件。磁盘文件的组织形式类似B树，但是对于磁盘顺序访问做了优化，其中每个文件都被完全填充为单页或多页的block，而这些文件的update本身是rolling merge策略，即系统在直到block写满的时候才将in memory的数据打包。因为flush是经常进行的，导致系统中会有很多的文件，一个后台进程在不断的合并小文件到大文件从而将磁盘seek缩减到少量的文件范围。于此同时，磁盘的树也可以进行分裂操作，将大文件分割为若干文件以便扩展更新。而所有的存储都是key有序的。

19，Hbase查询时，先到in memory里查，再到on disk里查，这样的行为可以保证了一致性；删除时是逻辑删除，先将delete标志打上，后期在异步重写的时候，标记了delete的key会被最终物理删除。

20，HBase有两类文件，一类用于WAL的log，另一类用于数据存储。

21，一般HBase的访问流程是：先到zookeeper quorum取row key，通过从zk中查询-ROOT-里的服务器名字实现；接着拿着取到的服务器名字去region server查询持有.META. 表region并且包含了rowkey的server名字；最后查询.META.服务器，获取到包含对应rowkey region的server name。一旦获取这些信息，客户端将其缓存起来，以后就知道如何到哪里去查找并且直接和region server联系了。

22，在源码级别，HMaster负责分配HRegionServer，HRegionServer维护一个HRegion，当HRegion建立时，为每张表的每个HColumnFamily建立一个Store，每个Store包含一个或者多个StoreFile（轻量级的HFile包装），一个Store同时也有一个MemStore，还有一个HRegionServer共享的HLog。

23，在做put操作时，region server先检查本次put是否需要写WAL，一旦数据写入WAL，那么它就进入MemStore，同时检查MemStore是否满，如果是，做一次flush，写到一个HFile里存到HDFS，同时维护一个最后一次写入的序列号，以便系统知道到目前为止的持久数据信息。

24，在HFile被持久化后，log文件就不再有用了，这时自动从.log目录移动到.oldlog目录（当然也有配置可以配置滚动周期），默认10分钟后由HBase自动删除。

25，每个table有一个目录，在这个目录里，每个列族有一个自己的目录。

26，region split发生在当一个region的存储文件大小达到配置的hbase.hregion.max.filesize时进行。具体过程就是：系统为新的region创建两个原region的索引文件，每个各持有原来一半的数据，region server在父region创建一个splits目录，接着关闭region拒绝新请求，然后再splits目录里构建必要的新的region目录文件结构存放刚才的两个half 大小的文件。成功后，系统将两个新的region目录添加到表目录，更新.META.表以表明父region做了split，同时表明新的两个region是什么。

27，HFile基于Hadoop的TFile类型，模仿了BigTable的SSTable格式；文件是变长的，其中定长的部分是file info 和trailer，而数据以keyvalue存入data块，默认大小64KB，而HDFS默认块大小是64MB，两者没有关系。结构类似：

28，KeyValue在HFile中就是一个简单的字节序列，结构类似

29，WAL是容灾的重要武器，类似mysql的binlog，记录了所有的变化，这就可以保证在数据进入memstore后而没有持久这段时间因为突发原因导致数据丢失时候的容灾。流程如下：

30，在上面这图中，有LogSyncer和LogRoller，前者是默认关闭的，如果开启后，那么每次写入都会触发一次sync，将update同步到其他的server，而且还是pipeline形式的顺序写，不是多路复写；后者负责滚动记录log，可以设置时间间隔每隔一定时间来滚动日志，也可以根据大小来滚动，这个都可以配置。

31，容灾恢复数据的一项重要措施是replay日志，也就是重放WAL；日志回放有两种触发条件：一是集群启动时，二是服务器fail时；当master启动时，检查.log目录里是否有log文件，有的话则做log splitting——读入log然后根据记录的region将其分配到新文件。

32，get和scan在近几个版本中实现等价，因为对于特定行和列没有索引的概念，而最小的访问单元是block，因此如果要请求数据，那么一定会加载一个RegionServer的实例的block然后扫描它，Get其实就是一个确定了row的scan。

33，在查询时，一个周期是这样的：因为客户端缓存region的，所以，会先到自己的cache中查找对应region，找到的话则直接访问（1次网络请求即可），如果找不到，则到region server的.META.中去取（3次），如果再找不到，则到-ROOT-找.META.信息（5次），再找不到，只好去zk中取（7次）（这是第21条tip的逆过程） 。

34，region有9种状态（offline,pending open,opening,open,pending close,closing,closed,splitting,split），状态转移可以再master做，也可以在持有region的region server上做。集群通过zk来跟踪状态变化。

35，Hbase的复制策略为容灾提供了高可用，基本模式是：master-push，因为WAL的存在，跟踪复制变得很容易；一个master cluster可以复制到任意数量的slave clusters，region server负责自己的复制。

1. jvm为每个装载的类和接口保存一份独立的常量池。
2. 动态加载最常用的是Class.forName()，这个方法有两个重载版本：Class.forName(String name)和Class.forName(String name, boolean init, ClassLoader loader)。它们均内部调用了forName0(String name, boolean initialize,ClassLoader loader)，这是个native方法。前者调用传递的参数是name、true和启动类加载器。name是要加载类的全限定名，init表明是否要初始化，如果这个类已经被初始化过，这样的加载即使init是true也不会被再初始化，loader是要加载的类加载器，null的话使用默认的启动类加载器。
3. 另一种方式动态加载类就是ClassLoader.loadClass()方法，这个方法也是两个重载版本：ClassLoader.loadClass(String name)和ClassLoader.loadClass(String name, boolean resolve)，其中前者调用了后者，resolve传递false，resolve表示是否在装载时执行该类的连接。
4. loadClass不初始化类，而forName初始化类，因此如果是需要动态加载类，该类马上被用到那么应该初始化，loadClass只加载，有可能出问题，但是会有安全考虑。
5. 常量池解析：上一篇日志也记录到了，在完成验证和准备后，要进入解析阶段，而解析主要做的就是解析常量池，把符号引用转为直接引用。
6. 对常量池CONSTANT_Class_info的解析，主要解析类和接口的符号引用，有两种入口：1）数组类，指向数组类的符号引用最后解析为一个Class的实例，如果数组的元素类型是引用类型，虚拟机用当前类加载器解析类型，如果数组是基本类型，虚拟机会立即创建关于那个元素类型的新数组类，确定维数，然后创建Class实例表示这个类，由启动类加载器定义。2）非数组类，第一步，装载类型或者任何超类型，先确定引用类型已经被当前类装载器装载过，虚拟机保证每一个类装载器都只装载一个给定名字的类型，这个步骤只是确定类型是否被装载，期间可能抛出的异常有：NoClassDefFoundError，ClassNotFoundError，ClassFormatError，UnsupportedClassVersionError，LinkageError，ClassCircularityError，IncompatibleClassChangeError；第二步，检查访问权限，如果发起引用的类型没有访问被引用类型的权限，jvm抛出IllegalAccessError；第三步，校验类型，出错则抛出VerifyError；第四步，准备类型，前面讲过，就是为不同类型分配内存；第五步，可选的解析类型，第六步，初始化。
7. 对常量池CONSTANT_Fieldref_info的解析，完成对Class_info的解析后，JVM按照一定顺序搜索字段：在被引用的类型中查找具有指定名字和类型的字段，找不到，则检查类型直接实现或扩展的接口，递归检查其超接口，如果还找不到，检查类型直接的超类，并递归检查其所有超类，如果找不到，则失败，抛出NoSuchFieldError异常。找到字段，但是没有访问权限，抛出IllegalAccessError异常。解析完后标记该常量池入口为已解析，并在数据中放入指向这个字段的直接引用。
8. 对常量池CONSTANT_Methodref_info的解析，完成对Class_info的解析后，JVM按照一定顺序搜索方法：如果被解析类型是一个接口，虚拟机抛出IncompatibleClassChangeError异常，如果是个类，JVM检查被引用的类是否有一个方法符合指定的名字以及描述符，如果不符合，找该类的超类，并递归找所有超类，还是找不到，虚拟机检查该类是否直接实现了任何接口，并递归检查接口的超接口，还找不到，则抛出NoSuchMethodError异常，如果找到但是没有访问权限，抛出IllegalAccessError异常。解析完后标记常量池入口为已解析，并在数据中放入指向这个方法的直接引用。
9. 对常量池CONSTANT_InterfaceMethodref_info的解析，完成对Class_info的解析后，JVM按照一定顺序在接口和它的超类型中搜索方法：如果被解析的类型不是接口是类，抛出IncompatibleClassChangeError异常，否则检查接口是否有符合指定名字和限定符的方法，如果没有，JVM检查接口的直接超接口并递归检查所有超接口以及java.lang.Object类来找，如果还没有，抛出NoSuchMethodError异常。解析完后标记常量池入口为已解析，并在数据中放入指向这个方法的直接引用。

1. 一个java类经过装载、连接和初始化三步达到程序可用状态，其中连接又包含验证、准备和可选的解析过程，验证是检查数据格式、准备是分配内存、解析负责把常量池的符号引用转换为直接引用。
2. jvm必须在每个类或接口首次主动使用时初始化，有六种主动使用场景：1）创建某个类的新实例，2）调用某个类的静态方法，3）使用某个类或接口的静态字段，用final修饰的静态字段除外，它被初始化为一个编译时的常量表达式，4）调用Java api中的某些反射方法，5）初始化某个类的子类，6）虚拟机启动时某个被标明为启动类的类（含有main方法的类）。
3. 某个类要初始化，其所有的祖先类必须之前被初始化；接口则不同，只有在某个接口声明的非常量字段被使用时，该接口才初始化。
4. 类装载的三个基本动作：通过完全限定名找到二进制数据流，解析为方法区内的数据结构，创建一个该类型的java.lang.Class的实例。
5. 类装载有可能存在预先装载，在预先装载时出问题，会抛出一个LinkageError的异常。
6. 在准备阶段，内存分配是初始化为默认值的，而不是实际的初始值。默认值列表如下：

   类型	默认初始值
   int	0
   long	0L
   short	(short)0
   char	'\u0000'
   byte	(byte)0
   boolean	false
   reference	null
   float	0.0f
   double	0.0d

7. 在准备和解析完后，才进入初始化阶段，为变量赋予真正的初始值。
8. 初始化类的步骤：1）如果类存在直接超类，且直接超类还没有被初始化，就先初始化直接超类。2）如果类存在一个类初始化方法，就执行此方法。
9. 第一个被初始化的类永远都是Object。
10. 所有的类变量初始化语句和类型的静态初始化器都被java编译器收集在一起，放到一个特殊的方法中——<clinit>。
11. 如果接口包含任何不能在编译时被解析成为一个常量的字段初始化语句，接口就会拥有一个<clinit>方法。
12. 类变量如果直接赋常量值，那么类是不会初始化的。
13. 类实例化的四种途径：1）new操作符。2）调用Class或Constructor的newInstance()方法。3）调用任何现有对象的clone()方法。4）通过ObjectInputStream的readObject()方法反序列化。
14. JVM为它编译的每一个类都至少生成一个实例初始化方法<init>。
15. 使用启动类装载器装载的类，永远都不会被垃圾收集。

class Act {

    public static void doMathForever() {
        int i = 0;
        for (;;) {
            i += 1;
            i *= 2;
        }
    }
}

class文件hex形式：

CA FE BA BE 00 03 00 2D  00 11 07 00 07 07 00 10
0A 00 02 00 04 0C 00 06  00 05 01 00 03 28 29 56
01 00 06 3C 69 6E 69 74  3E 01 00 03 41 63 74 01
00 08 41 63 74 2E 6A 61  76 61 01 00 04 43 6F 64
65 01 00 0D 43 6F 6E 73  74 61 6E 74 56 61 6C 75
65 01 00 0A 45 78 63 65  70 74 69 6F 6E 73 01 00
0F 4C 69 6E 65 4E 75 6D  62 65 72 54 61 62 6C 65
01 00 0E 4C 6F 63 61 6C  56 61 72 69 61 62 6C 65
73 01 00 0A 53 6F 75 72  63 65 46 69 6C 65 01 00
0D 64 6F 4D 61 74 68 46  6F 72 65 76 65 72 01 00
10 6A 61 76 61 2F 6C 61  6E 67 2F 4F 62 6A 65 63
74 00 20 00 01 00 02 00  00 00 00 00 02 00 09 00
0F 00 05 00 01 00 09 00  00 00 30 00 02 00 01 00
00 00 0C 03 3B 84 00 01  1A 05 68 3B A7 FF F9 00
00 00 01 00 0C 00 00 00  12 00 04 00 00 00 05 00
02 00 07 00 05 00 08 00  09 00 06 00 00 00 06 00
05 00 01 00 09 00 00 00  1D 00 01 00 01 00 00 00
05 2A B7 00 03 B1 00 00  00 01 00 0C 00 00 00 06
00 01 00 00 00 02 00 01  00 0E 00 00 00 02 00 08

1. java的class文件是8位二进制流，数据项按顺序存放，无间隔，占多字节的数据项以高位在前的顺序分几个字节存放；
2. java class基本类型：u1,u2,u4,u8，分别对应：1,2,4,8字节的无符号类型；
3. java class file表格展示：（太大了，来个url自己看吧，wikipedia）
4. 表项详解：1）magic（魔数）：说白了就是cafebabe，本来java就是咖啡嘛，这4个字节用来区分是否是java的class文件，有则是；2）minor_version&major_version：两个字节的minor和两个字节的major，以上为例就是minor：3，major：2D（JDK 1.1）；3）再之后就是常量池了，2个字节表示constant_pool_count，本例是17，表示class文件中常量池中的项数（比实际的大1），接着就是常量池，连续的constant_pool_count-1个字节存储常量池各个入口，常量池入口项解释见本文第5条笔记；4）在之后的是access_flags：2个字节表示访问类型，是类还是接口，是public还是private，abstract或者final等等，标志位具体定义见本文第6条笔记，本例是00 20，表示老版本ACC_SUPER；5)之后是this_class，这是2字节的一个对常量池的索引，本例是00 01，即本例的自身类叫做Act；6）之后就是super_class，也是一个2字节常量池索引，指向父类的名字， 本例是00 02，即java.lang.Object；7）interface_count和interfaces：interface_count指出本文件有多少直接实现或者由接口扩展的父接口的数量，本例没有，故为00 00，之后是interfaces的具体内容，实际的项数就是之前的interface_count数，因为interface_count=0，所以本例的interfaces就没有值；8）接下来是fields_count和fields：对本类所声明的字段的描述，首先是个2字节的count，本例是00 00，所以后续也没有fields的项；9）再之后就是methods_count和methods了，count是一个2字节数据，本例的method_count是00 02，这个count只表示在类或接口中显式定义的方法，继承的方法不计数，count后是method_info的表，包含方法的一些信息如方法名、描述符等，本例中00 09表明方法是public（01）&static（08），00 0F是方法名的常量池入口，即常量池的第15项doMathForever，再下来00 05是方法描述符常量池入口，即常量池第5项：()V，然后00 01是属性表的count数，表示1项属性，接下来是00 09表示属性表的常量池入口即常量池第9项Code，接下来的4个字节00 00 00 30表示code属性长度：48字节，接着00 02是操作数最大数，然后00 01是局部变量存储长度，这里方法里只有一个变量i，所以是1，然后00 00 00 0c是code字节码长度12，然后的12个字节就是字节码code了，再后的00 00是异常数，之后异常栈数是0，跳过，就是00 01的属性数，然后00 0C指向常量池的第12项即LineNumberTable，这是一个code属性，之后的00 00 00 12是属性长度，再后的00 04是line_number_info表的项数，接下来的4项（每项4字节）表示line_number_info，00 00 表示代码偏移量，00 05表示代码行号，后面的类似；10）最后是attributes_count和attributes，表明了类的属性，属性比较特殊，jvm定义了两种属性：SourceCode和InnerClass。
5. 常量池各个标志解读（来源wikipedia） ，这里详解一下本例中的常量池，常量池是

   cp_info
          {
              tag;
              info[];
          }

   类似这样的结构，先有一个无符号byte作为tag标志，对应表格中的数据，额外的info字节数组存储对应的数据index.
   我以表格的形式列出常量池的所有数据，应该算一目了然了吧：

6. 常量index	标志	标志内容	字节	具体数据	实际含义
   1	07	00 07	2	class reference	常量池第7项是该class的内容
   2	07	00 10	2	class reference	常量池第16项是该class的内容
   3	0A	00 02 00 04	4	method ref	两个index，前两个字节表示池内的class索引位置，后两个字节是名字和类型描述
   4	0C	00 06 00 05	4	name & type	就是第3项方法指向的名字和类型的index
   5	01	00 03	2+x	x个utf-8字符，此处x=3	实际值：()V，表示type（第三项方法的类型，具体含义参见描述符定义）
   6	01	00 06	2+x	x=6	实际值：<init>，表示name（第三项方法的名字）
   7	01	00 03	2+x	x=3	实际值：Act，第一项指向的具体字符内容
   8	01	00 08	2+x	x=8	实际值：Act.java，
   9	01	00 04	2+x	x=4	实际值：Code
   10	01	00 0D	2+x	x=0D=13	实际值：ConstantValue
   11	01	00 0A	2+x	x=0A=10	实际值：Exceptions
   12	01	00 0F	2+x	x=0F=15	实际值：LineNumberTable
   13	01	00 0E	2+x	x=0E=14	实际值：LocalVariable
   14	01	00 0A	2+x	x=0A=10	实际值：SourceFile
   15	01	00 0D	2+x	x=0D=13	实际值：doMathForever
   16	01	00 10	2+x	x=10=16	实际值：java/lang/Object

7. 访问标志，待完善，这里有详细的spec
8. 描述符的完整定义：非终结符是正常体，终结符是粗体，*号表示之前符号出现0或多次

   FieldDescriptor	FieldType
   ComponentType	FieldType
   FieldType	BaseType,ObjectType,ArrayType
   BaseType	B,C,D,F,I,J,S,Z
   ObjectType	L<classname>;
   ArrayType	[ComponentType
   MethodDescriptor	(ParameterDescriptor*)ReturnDescriptor
   ParameterDescriptor	FieldType
   ReturnDescriptor	FieldType,V

9. 基本类型终结符：V代表void

   终结符	类型
   B	byte
   C	char
   D	double
   F	float
   I	int
   J	long
   S	short
   Z	boolean

10. 一些描述符的例子：

    描述符	字段或方法声明
    I	int a;
    [[J	long[][] b;
    [Ljava/lang/Object;	java.lang.Object[] c;
    Ljava/util/HashMap;	java.util.HashMap map;
    [[[Z	boolean[][][] ok;
    ()I	int m1();
    ()Ljava/lang/String;	String m2();
    ([Ljava/lang/String;)V	void main(String[] args);
    ()V	void m3();
    (JI)V	void m4(long a,int b);
    (Z[Ljava/lang/String;II)Z	boolean m5(boolean a,String[] b,int c, int d);
    ([BII)I	int m6(byte[] a,int b,int c);

11. 声明字段时的字段表field_info：

    类型	名称	数量	含义
    u2	access_flags	1	访问标志
    u2	name_index	1	字段简单名称的常量池utf8_info入口索引
    u2	descriptor_index	1	字段描述符的常量池utf8_info入口索引
    u2	attributes_count	1	attribute_info表的项数
    attribute_info	attributes	attributes_count	字段属性：ConstantValue, Deprecated, Synthetic（JVM规范）

12. field_info中的access_flags标志含义：

    标志名	值	含义	使用范围
    ACC_PUBLIC	0x0001	public	类和接口
    ACC_PRIVATE	0x0002	private	类
    ACC_PROTECTED	0x0004	protected	类
    ACC_STATIC	0x0008	static	类和接口
    ACC_FINAL	0x0010	final	类和接口
    ACC_VOLATILE	0x0040	volatile	类
    ACC_TRANSIENT	0x0080	transient	类

13. 声明方法时的方法表method_info：

    类型	名称	数量	含义
    u2	access_flags	1	访问修饰符
    u2	name_index	1	方法简单名称的常量池入口
    u2	descriptor_index	1	方法描述符的常量池入口
    u2	attributes_count	1	属性表的项数
    attribute_info	attributes	attributes_count	方法属性：Code,Deprecated, Exceptions和Synthetic（JVM规范）

14. method_info表中的访问标志对应含义：值得说明的是接口的方法一定是public和abstract的，接口初始化方法可以用strictFP

    标志名	值	含义	使用范围
    ACC_PUBLIC	0x0001	public	类和接口
    ACC_PRIVATE	0x0002	private	类
    ACC_PROTECTED	0x0004	protected	类
    ACC_STATIC	0x0008	static	类
    ACC_FINAL	0x0010	final	类
    ACC_SYNCHRONIZED	0x0020	synchronized	类
    ACC_NATIVE	0x0100	native	类
    ACC_ABSTRACT	0x0400	abstract	类和接口
    ACC_STRICT	0x0800	strictFP	类和接口的<clinit>方法

15. 类和接口的初始化方法(<clinit>)只有JVM可以直接调用，永远不会被java字节码直接调用。
16. JVM规范定义的所有属性：

    属性名	使用者	描述
    Code	method_info	方法的字节码和其他数据
    ConstantValue	field_info	final变量的值
    Deprecated	field_info,method_info	字段或方法被禁用的指示符
    Exceptions	method_info	方法可能抛出的可被检测的异常
    InnerClasses	ClassFile	内部、外部类的列表
    LineNumberTable	Code_attribute	方法的行号与字节码的映射
    LocalVariableTable	Code_attribute	方法的局部变量的描述
    SourceFile	ClassFile	源文件名
    Synthetic	field_info,method_info	编译器产生的字段或者方法的指示符

17. code属性的表code_attribute：

    类型	名称	数量	含义
    u2	attribute_name_index	1	包含“Code”的常量池入口
    u4	attribute_length	1	去除起始6个字节后的code属性长度
    u2	max_stack	1	方法执行任意时刻，该方法操作数栈的最大长度（以字为单位）
    u2	max_locals	1	方法局部变量需要的存储空间长度（以字为单位）
    u4	code_length	1	该方法字节码流的长度
    u1	code	code_length
    u2	exception_table_length	1	异常表项数
    exception_info	exception_table	exception_table_length	异常表
    u2	attributes_count	1	属性数
    attribute_info	attributes	attributes_count	code属性：LineNumberTable和LocalVariableTable（JVM规范）

18. 异常表excption_info：

    类型	名称	数量	含义
    u2	start_pc	1	代码数组起始处到异常处理器起始处的代码偏移量
    u2	end_pc	1	代码数组起始处到异常处理器结束后的一个字节的偏移量
    u2	handler_pc	1	代码数组起始处跳转到异常处理器的第一条指令的偏移量
    u2	catch_type	1	异常处理器捕获的异常类型的Class_info常量池入口，如果为0则表示处理finally子句，即处理所有异常

19. constantValue属性：各种基础类型加字符串类型的常量池入口查找，结构很简单，这里就不列出了。
20. LineNumberTable属性建立了方法字节码流便宜量和源代码行号之间的映射关系：

    类型	名称	数量	含义
    u2	attribute_name_index	1	包含“LineNumberTable”的常量池入口
    u4	attribute_length	1	去除起始6字节后的属性长度
    u2	line_number_table_length	1	line_number_info表长度
    line_number_info	line_number_table	line_number_ table_length	属性表

21. line_number_info表很简单，就两个项：u2的start_pc给出新行开始时代码数组的偏移量，u2的line_number给出了从start_pc开始的行号。

这次就到这里。to be continued...

今天先开个头。笔记是无结构的流式记录，类似tips的list吧~

1. 每个java程序运行于自己的JVM实例中，java程序的启动入口必须是public static void main(String[] args)；
2. 每个java程序，开始于main，结束于所有非守护线程的终止；
3. jvm的体系结构包含：类装载器子系统（装载class）、运行时数据区（存放数据）、执行引擎（执行被装载类的指令）；
4. 运行时数据区包含：堆、方法区、java栈、本地方法栈、PC寄存器。其中堆和方法区是所有线程共享的，而其他三者是线程独享的；
5. jvm数据类型分两种：基本类型{数值类型{浮点数{float,double}，整数{byte,short,int,long,char}}，boolean，returnAddress}和引用类型{引用{类，接口，数组}}，基本类型存数据本身，引用类型存数据引用；
6. boolean是个特别的类型，jvm处理按int来操作，0为false，非0为true，boolean数组是按byte数组来访问的；
7. 引用类型中，类和接口都是对类或者实现了接口的类的实例的引用，数组是对数组对象的引用，一个特殊引用是null，表示没有引用任何对象；
8. 数据类型取值范围：{byte：1字节有符号，short：2字节有符号，int：4字节有符号，long：8字节有符号，char：2字节无符号，float：4字节IEEE754单精度，double：8字节IEEE754双精度，returnAddress：统一方法中某操作码的地址，reference：堆中对象的引用或null}
9. JVM数据单元是字，字长的设计最短要32bit即4个字节，保证能容纳byte，short，int，char，float，returnAddress和reference类型的值；
10. JVM有两种类加载器：启动类装载器和用户自定义类装载器，前者是jvm实现的一部分，后者是java程序的一部分，不同类装载器装载的类被放在虚拟机内部不同的命名空间；
11. 方法区存储：{类加载时，读入class文件后，解析得到的类型信息：全限定名，直接父类的全限定名，是类类型还是接口类型，访问修饰符，直接实现接口的全限定名有序列表}，{常量池：直接常量（string，int等）和对其他类型、字段和方法的符号引用}，{字段信息：字段名，字段类型，字段修饰符}，{方法信息：方法名，方法返回类型，方法参数的数量和类型，方法的修饰符}，{类变量：static}，{编译时常量：final}，{指向ClassLoader的引用：如果是自定义装载的}，{指向Class类的引用：Class.forName()或者object.getClass()}，{方法表：虚拟机为每个非抽象类生成一个方法表}；
12. 堆存储：所有运行时创建的类实例或数组都放到同一个堆中；
13. 程序计数器：大小1个字长，内容总是下一条将被执行指令的地址；
14. java栈：只有push和pop操作，单位是一个栈帧，保存线程的运行状态，每个帧中存储当前的参数、局部变量、中间运算结果等。当方法以return或者异常抛出结束时，当前帧pop，当调用一个java方法时，push一个帧成为当前帧。因为java栈数据是每线程私有的，可以不考虑同步问题。java栈的每个栈帧又包含三部分：局部变量区、操作数栈和帧数据区。局部变量和方法参数存入局部变量区，操作数栈是jvm的工作区，指令都要经过栈弹出数据进行运算，一般的iload,istore等指令就是push和pop；帧数据区主要是支持常量池解析、正常方法返回以及异常派发机制；
15. 本地方法栈：线程调用一个本地方法时，本地方法接口使用本地方法栈；
16. 执行引擎：执行指令，通用技术有解释、即时编译、自适应优化和芯片级执行，Sun的hotspot使用自适应优化：刚开始对所有代码解释运行，监视代码运行情况，把经常执行的代码编译为本地代码，优化，然后继续执行。

假设一个场景，一个网站，想对登陆用户进行消息提醒，那么如何选择技术实现呢？现在大多数的实现是轮询——也就是间隔拉技术，定时的用ajax请求访问server，将返回的数据更新到页面上，通过间隔拉取来模拟出push的效果。但这毕竟还不是推，而且存在的核心问题就是请求浪费，资源浪费，本可避免的服务器端压力，总之一句话：低效率。

单纯的服务器端推：

1，http服务一般是做长连接的，连接不断开，那么当有事件发生时，服务器端可以定向的向持有连接的客户端push数据。

2，http响应header里的content-type设置为multipart/mixed这样的MIME，这种技术可以通过boundary来在header的content-type里设置一个边界值，客户端通过解析边界值来区分不同的显示部分。换句话说，服务器端告诉客户端这个响应是有多个部分的，客户端应该通过boundary来区分这些部分并分别处理。这种技术有个明显的劣势是IE不支持，多数是被用到webcam这样的应用中。

3，websocket，html5才支持的最新技术，优点嘛自然是高效，但是缺点就是客户端浏览器的支持度了。

另外的几种技术：

1，pushlet：与刚才1中提到一样的持久连接，服务端定期的返回js片段给到客户端，客户端持续显示loading状态，在收到js后执行，将结果更新到页面上。缺点的话是服务器端对客户端超时的控制没有掌握，在超时后，只有客户端主动刷新才能解决。详细优缺点参看这篇文章

2，长轮询：与传统定时轮询不同，长轮询会在服务器端阻塞请求，直到有数据的时候再做响应，而服务器端在接到响应后马上重新请求，如此往复。具体可以参看这篇文章

3，Flash XML Socket relays：通过加入一个relay服务器，这个服务器接收到客户端的一个请求，且这个请求基于tcp的连接，然后relay会返回一个id给到客户端，然后客户端会带着这个id请求web服务器，web服务器会把响应消息给到relay，relay再通过flash socket分发出去。当然tcp并发连接就是个瓶颈，但是这种做法的效率很高，对于小规模实现有益。

众所周知的服务器端推就是comet技术了，长轮询其实也是一种comet技术。comet技术本身是个泛化了的概念，具体实现可以有多种，但是通用且多数的实现时基于XHR（XMLHttpRequest）的ajax长轮询。

对于具体的业务场景，我们可能选择不同的服务器端推策略，对于现有的web应用比如聊天和消息可能TCP或者长连接就能解决问题，但是对于大并发下的大型网站，拉取是更合适的选择，长轮询可能用的会多一些。当然我们最期望的是websocket的表现~

参考文章：

http://en.wikipedia.org/wiki/Push_technology

http://en.wikipedia.org/wiki/Extensible_Messaging_and_Presence_Protocol

http://en.wikipedia.org/wiki/Internet_Relay_Chat

http://en.wikipedia.org/wiki/Comet_(programming)

http://en.wikipedia.org/wiki/MIME#Mixed-Replace_.28experimental.29

turbine是什么？

turbine是一个应用开发框架，是一个开发web应用的工具箱，100%纯java，且基于jdk1.3及以上。j2ee兼容且基于servlet，面向MVC构建。

turbine的框架架构overview如下：

turbine的代码结构包含了services、modules和util几个大类，在上图中可见，在servlet基础之上，以MVC为基础结构，modules包含了view部分及action，view主要是pages，其中有三种具体的module——screen、layout和navigation，action作为controller存在，toolbox提供了很多通用的tool，service则是整个框架的插件。一个完整的请求处理流程如下：

请求到来，turbine的controller处理，view部分渲染页面，然后响应输出。

就顺着这个流程，分析一下turbine的架构，对于view部分，我们最直观想到的就是pages，page模块值包含了几个概念，是jsp的？还是velocity的？仅此而已。那么，以一个velocity页面为例，如何组织呢？turbine讲究的是“约定胜于配置”，记住这句真言，也就可以理解turbine了。在开发应用中，要建立三个页面目录，分别是screen、layout和navigation，screen是页面的主体内容，layout是页面的布局，而navigation则是一些页面修饰元素，比如下面这个页面结构：

这三个部分的调用顺序如下：

因为约定的代码结构是在三个目录下写对应名字的java代码，因此名字如果不一致，那么就会出错。当然，页面模板目录有默认的结构，如果在对应的目录下找不到文件，就会读取default.vm文件。

类似servlet，写一个java文件对应处理screen页面，那么代码可能是这样的：

可以看到，这种处理代码很像servlet，方法就像是servlet标准中的doGet和doPost，只不过参数进行了封装。其实，turbine就是一个servlet，看看turbine的源码，Turbine类继承了HttpServlet，实现了doGet和doPost方法，除了一开始初始化一系列配置相关的变量外，在接到一个http请求（get）后，turbine会执行doGet方法，turbine封装了request和response，构建了一个叫做RunData的对象，Rundata是个接口，具体实现是DefaultTurbineRunData，其内部提供了获取http各种数据的方法接口。在每个请求周期，turbine都会利用TurbineRunDataService新建一个RunData，将所有基于servlet的请求相关的东西塞到这个data中。然后，利用从request中得到的请求地址，再调用PageLoader找到对应的Page，执行其中的build方法，其中DefaultPage里会通过LayoutLoader和ScreenLoader来定位到对应的layout和screen，然后执行其中的build相关方法。这样，一整套请求执行就完成了。值得说明的就是如果是表单提交，那么多数情况会多出一个action的执行，也是在page里进行的。如下图

至于turbine中的tool，这类工具是通过配置，以“拉”模式被应用的。当应用启动后，在vm页面中以$开始调用某个tool的时候，就会初始化这个tool。当然，这里就用到了TurbinePullService。

在初步了解了turbine后，如果使用过webx，那么就会知道并一定程度理解了webx的设计；没使用过的，结合自己用过的mvc框架，也可以了解一些框架设计的思路。

参考资料：

Turbine Tutorial

Apache Turbine

本文全部图片都截取自Turbine Tutorial，使用请注明

在commons-io这个开源框架中，封装了对io的基本操作，其中org.apache.commons.io.comparator包就是经典的设计典范，comparator顾名思义就是为了提供一系列的文件排序器，辅助排序。这里我把结构图画一下：

一个AbstractFileComparator抽象类完成了一层包内抽象，直接实现接口Comparator<File>，并且提供了sort方法完成了通过比较的排序功能：

public File[] sort(File... files) {
        if (files != null) {
            Arrays.sort(files, this);
        }
        return files;
    }

public List<File> sort(List<File> files) {
        if (files != null) {
            Collections.sort(files, this);
        }
        return files;
    }

所有的具体排序器实现都继承了这个AbstractFileComparator抽象类，实现compare方法，完成各自的比较，比如有根据文件大小比较的SizeFileComparator，有根据修改时间比较的LastModifiedFileComparator等等。值得一提的就是用到了委托的ReverseComparator和CompositeFileComparator，Reverse顾名思义就是反转排序，默认的排序器都是升序的，谁小把谁排在前面，ReverseComparator通过代理一个Comparator

private final Comparator<File> delegate;

构造时作为参数把delegate实例化，public ReverseComparator(Comparator<File> delegate)，最后实现compare方法：

public int compare(File file1, File file2) {
       return delegate.compare(file2, file1); // parameters switched round
   }

完成整个反转排序的功能，看出端倪了吧。一个代理的引入，减少了一半的工作量，把排序功能实现的非常全面。

同理，组合排序器的实现正好利用了多维的代理

private final Comparator<File>[] delegates;

构造时传入的参数是一个可变长度数组，public CompositeFileComparator(Comparator<File>... delegates)，或者一个可迭代对象，public CompositeFileComparator(Iterable<Comparator<File>> delegates)，实现的compare方法如下：

public int compare(File file1, File file2) {
        int result = 0;
        for (Comparator<File> delegate : delegates) {
            result = delegate.compare(file1, file2);
            if (result != 0) {
                break;
            }
        }
        return result;
    }

组合排序就是提供一系列排序器，顺序比较，直到出现不相等情况。考虑到实际应用，我们经常是否只是实现了Comparable接口，在compareTo方法中写if else呢？引入代理的排序器api设计，给了我们不错的启示。

logback可以认为是log4j的升级版，依然出自Ceki Gülcü，使用简单，只需要在你的classpath里包含slf4j-api.jar、logback-core.jar以及logback-classic.jar即可。

简单代码示例如下：

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import ch.qos.logback.classic.LoggerContext;
import ch.qos.logback.core.util.StatusPrinter;
public class LogTest {

    public static void main(String[] args) {

        Logger logger = LoggerFactory
                .getLogger(LogTest .class.getName());
        logger.debug("Hello world.");

}

其中的logger对象和LoggerFactory都来自slf4j项目，slf4j是一个很好的facade，包装了接口，就像之前写的一篇文章中的提到的commons-logging框架。

同样也可以认为logback+slf4j是log4j+commons-logging的升级版吧。

logback的架构：

logback包含3个子工程——classic、core和access。core是其他两个的基础，也是logback的核心；classic扩展了core，内置了slf4j，但也支持各种其他log门面。同log4j一样，logback的主要构成也是Logger、Appender和Layout。Logger是核心控制器及调用入口，Appender主管配置和写日志实际process，Layout控制日志样式，是Appender的重要配置。值得注意的是，3个基本核心居然不都在core模块中，Logger是在classic里的。

对于Logger来讲，和Log4j一样，Logger是一个层次结构，每个logger都有一个name属性在LoggerFactory中被一个map管理着。对于Logback来说，这个factory就是classic下的LoggerContext。这里插一段自我理解，在做facade模式的时候，代码结构可能会引入一个占位性质的类，就像slf4j中的StaticLoggerBinder，这个类在org.slf4j.impl包下，是一个单例，但是私有构造函数却抛出了一个异常，这个在不熟悉这种写法时会产生困惑。其实这是很合理的，logback的classic中也有org.slf4j.impl这个包，其中也有StaticLoggerBinder这个类，但是内容完整了许多。这就完成了slf4j的任务，同时解除了耦合。我认为这种解耦合方式非常好，plugin的感觉。

再回来说LoggerContext，这个对应了log4j的LogManager和Hierarchy，用一个hashtable来维护logger的cache。代码真的是简洁了很多，再回头看看log4j中LogManager的getLogger方法，就知道logback的简洁了，一个while遍历省去了一个hierarchy。当然这里得补充一句，log4j包括logback的整个日志框架对于logger对象，是一个层次结构，这也是为什么log4j中有个Hierarchy的东西的原因。是一个层次的话，对于通过包名来管理日志记录等级的管理方式来说，就存在着level的控制，也就是说，你某个包名的类被设定了日志级别是什么，那么对应级别以下的日志才会被打印出来。有这样一个规则，logger的日志记录有效level由hierarchy中离它最近且方向向上（upwards）的一个logger的级别决定。如官网上的例子：

这里有4个logger，但是只有root被设定了level是DEBUG，其他几个logger由于没有被设定，依照规则，就都是root的level了。

第二个例子中，每个logger都自己设定了level，那么依据规则，离它最近的被使用，当然自己离自己最近了。

第三个例子里，X.Y没有设定level，那么离它最近且upwards的一个是X，那么X.Y的level就和X的一样。

level控制是日志框架的基础，什么样的日志在什么环境下被打印出来，这种设定可以配置才是一个合理的日志系统。一贯的level控制规则如下显示：

appender这个东西，和log4j是一样的，支持一个logger有多个appender，在AppenderAttachableImpl里会维护一个CopyOnWriteArrayList来存放一个logger的appender。每次log的时候都会遍历这个list里的appender然后调用对应的doAppend方法。我们在配置的时候每个logger的配置上有个additivity属性，默认为true。appender这个东西同logger一样有继承性。additivity属性就是控制这种继承的，true代表开启，false代表关闭，一般使用都会设置false，因为如果是true，那么如果appender比较多的话可能日志打的就有点太离谱了。

Layout和log4j一样，我没有细研究过，但是我认为这是控制输出的一大法宝，下次研究layout的时候做一个详细的分享，一般大家都使用patternLayout，写个表达式足以。

在之前的那篇写log的文章中，提到过一个优化写法，就是不要直接写出这样的代码：

logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i]));

构造string参数是复杂且耗时的。要用if判断一下。而slf4j提供了比较合适的解决方法：

Object entry = new SomeObject(); 
logger.debug("The entry is {}.", entry);

这样的代码就更符合程序设计人员的编写习惯，而且可读性我认为要远远高于用+号连接。但是遗憾的是，这种编码风格作者并没有持续贯彻下去，没有用变长参数，而是用的object[]终止了参数的个数。也就是说，你对于多个变量的log的话，只能这么写：

Object[] paramArray = {newVal, below, above};
logger.debug("Value {} was inserted between {} and {}.", paramArray);

在执行log的时候，会有一个判断流程，依据官网上的介绍，我简要翻译一下：

1，Get the filter chain decision：如果存在，尝试调用TurboFilter ，TurboFilter 会设置一个整个上下文范围的阈值或者过滤掉每个log请求的相关参数。如果这个filter返回的参数是FilterReply.DENY ，那么log结束；如果FilterReply.NEUTRAL返回，则进入第2步，如果FilterReply.ACCEPT ，直接第3步。

2， Apply the basic selection rule，如果log请求的阈值和高于配置的阈值，那么放弃处理该log。

3， Create a LoggingEvent object，logback会构建一个LoggingEvent对象，包含了所有的请求参数。其中有些参数可能是延迟加载的。

4， Invoking appenders，logback调用doAppend方法。

5， Formatting the output，layout会把LoggingEvent对象按固定格式格式化并返回字符串形式，像SocketAppender这样的方法不会返回字符串，相似的只会把它序列化。

6，  Sending out the LoggingEvent，把最终形式打印到对应的目的地址。

流程图见这里http://logback.qos.ch/manual/underTheHood.html

最后还是通过性能讨论结束这篇短文，性能的东西，我们不去看代码的话，是无法估计复杂度的变化的。那么就官网上给出的3条提示，第一点针对参数构建，第二点针对level的定位，这个在看过代码后，发现确实精简了，尤其是那种复杂的hierarchy结构没有了，线性的链条运行起来明显会快，算是去除冗余做了优化吧。第3条针对说format和write会快，尤其是format被大力投入改进，这个在看过代码后，可以做个比较。

本文算是一篇半自主半翻译的文章吧，重在学习。

参考文献：

http://logback.qos.ch/manual/introduction.html

#读锁（共享锁）、写锁（排他锁）：读锁是共享的，互不阻塞，读取同一资源互不影响；写锁排他，一个写锁会阻塞其他的读写操作。

#锁定对象的粒度：表锁和行锁。

表锁：整个表加锁，当写操作时，加写锁，资源访问排他。当没有写时，加读锁，读锁互不冲突。写锁比读锁有高优先级。开销较小。

行级锁：对一行加锁，开销大，支持最大并发处理。

#事务：ACID

A原子性：一个事务是一个原子不可分的工作单元，内部的工作不会被部分执行，要么全部执行，要么根本不执行

C一致性：数据库从一种一致状态转到另一种一致状态，事务执行过程中的数据改变不会影响数据库数据。

I 隔离性：某个事务的结果只有在事务完成后才对其他事务可见。

D持久性：一个事务提交后的结果改变将是持久的，不会马上消失。

#MVCC：多版本并发控制

#几个存储引擎：

MyISAM：加表锁，在select查询时可以在同一张表完成插入（并发插入），可以基于BLOB和TEXT的前500字符进行相关索引。

InnoDB：事务引擎，适合处理大量短期事务，基于聚簇索引，不压缩索引

Memory：基于堆的，内存存储，支持哈希索引

Archive：只支持insert和select，不支持索引，缓冲了数据写操作，插入时使用zlib算法压缩，比MyISAM磁盘IO消耗少，所有 的select查询执行全表扫描，适合logging，支持行级锁。

断断续续两周时间来看了看tomcat4的源码。虽然有点古旧，但是配合着《How tomcat works》一书看看源码，还是很惬意的事情。中途数次想拿起纸笔抑或打开word书写下笔记，但是书中简洁的文风让我觉得没有什么可以记下的。直到最后读完这书，过完源码。才觉得应该记下一些要点来。简单称之为总结吧。

其实搞懂tomcat或者是类似的servlet的工作原理，只要配合理解这张图就可以了。这就是tomcat的整个工作流程。

一个HTTP请求到来，其实本质上只是一个输入流，在这个流中蕴含了那些字节代表了这个请求的语义。而图中的1.message就抽象了这个流，把它表示为一条信息。在到达容器的第一时刻，容器是交给connector来处理的。首先这里得考虑一个容器的启动过程，启动时做的一个重要事情就是初始化connector，而connector初始化时干什么呢？显然，创建socket。一切初始化好了，才有第一步消息到来这件事情咯。

信息到了，connector干的事情就是如图中的2和3步——创建http请求对象和响应对象。当然这个行为也不是connector自己干的，它只是雇佣了一个叫做HttpProcessor的兄弟来干活。真正的creation都是这个兄弟干的。HttpProcessor里面设计了一些简单的并发多线程trick，基本上就是让socket等待着请求信息的到来，来一个，就处理一个。HttpProcessor的一句话总结就是利用多线程技术parse整个请求的stream。几个parse步骤分别是：解析connection；解析request；解析headers。补充一句，request和response对象都是在HttpProcessor初始化的时候初始化的，但是它们内容的填充是在parse的时候完成的。

接着，connector的任务就结束了。然后一个invoke其实就是工作的交接，该context重磅登场了。Context以其名字就决定了其霸气的侧漏无疑，基本上所有的东西都包含在内。我们把3的invoke当做一些context的自我设置（初始化），那么4的invoke就是context的表演开始了。首先在图里没有给出的是loader和logger的处理，context会在这两个依赖对象不为空的情况下运行它们。Loader是设置java class loader的，tomcat自己定义了一个classloader来加载特定的类。而logger无非就是把日志给启动起来。当然在启动pipeline之前做了启动subcontainer的操作。这是可以理解的，用计算机本质的递归来理解，有点像是先序遍历树的感觉。而pipeline被启动后，后续还有一个manager的启动，这个manager是主要用来管理session的。而所有这些都是可以配置的。

照着上图主要说说pipeline，pipeline就是流水线了，上面有很多的阀门valve，阀门可以自己加，pipeline的的工作就是步骤5，顺序invoke每个阀门。其实也不是pipeline启动，pipeline其实只是启动了内置的pipelineContext对象，而这个对象会不断的调用invokenext()方法来实现流水线的执行。而这些个valve会调用wrapper，他们的invoke方法会启动wrapper，在检测完mapping后，wrapper会allocate一个servlet实例，接着servlet启动、干活、开始自己的生命周期……这个世界就开始活跃了。

That is it

最后奉上一张稍微详细点的图帮助理解。

当然，美妙的设计这里没有讲，不是因为时间不够或者是空间不足，而是我自己还没有完全的消化，tomcat我认为从设计上讲，结构是beautiful的。光是lifecycle的设计以及各个类模块区分（connector，loader，context，wrapper以及manager等等）之间的初始化调用等细节每个拿出来都够写本书了。So~~~read the fucking source code by yourself。

参考资料：

《How tomcat works》

Tomcat 系统架构与设计模式，第 1 部分: 工作原理http://www.ibm.com/developerworks/cn/java/j-lo-tomcat1/

Velocity与struts结合应用：

具体通过一个实际的例子来解释，例子选择以传统的注册模块为主（主要是joseph的书上就这么写的）

首先，web.xml文件配置情况struts部分就不讲了，velocity的配置如下所示：

<servlet>

<servlet-name>velocity</servlet-name>

<servlet-class>org.apache.velocity.tools.view.servlet.

VelocityViewServlet</servlet-class>

<init-param>

<param-name>toolbox</param-name>

<param-value>/WEB-INF/toolbox.xml</param-value>

</init-param>

<load-on-startup>10</load-on-startup>

</servlet>

<!-- Action Servlet Mapping -->

<servlet-mapping>

<servlet-name>velocity</servlet-name>

<url-pattern>*.vm</url-pattern>

</servlet-mapping>

其中velocity的servlet配置中的初始参数传入了toolbox.xml，该文件的具体内容如下：

<?xml version="1.0"?>

<toolbox>

<tool>

<key>toolLoader</key>

<class>org.apache.velocity.tools.tools.ToolLoader</class>

</tool>

<tool>

<key>link</key>

<class>org.apache.velocity.tools.struts.LinkTool</class>

</tool>

<tool>

<key>msg</key>

<class>org.apache.velocity.tools.struts.MessageTool</class>

</tool>

<tool>

<key>errors</key>

<class>org.apache.velocity.tools.struts.ErrorsTool</class>

</tool>

<tool>

<key>form</key>

<class>org.apache.velocity.tools.struts.FormTool</class>

</tool>

</toolbox>

这个xml文件的意义就在于定义了很多类，来串联整个struts和velocity还有javabean等各个元素。

接着就开始配置struts了，首先考虑到这个应用，struts的第一步就是要写form了。首先构建一个RegisterForm。代码如下，这个javabean用来当做model定义数据。

package app;

import org.apache.struts.action.*;

publicclass RegisterForm extends ActionForm {

 protected String username;

 protected String password;

 protected String password2;

 public String getUsername() { returnthis.username; }

 public String getPassword() { returnthis.password; }

 public String getPassword2() { returnthis.password2; }

 publicvoid setUsername(String username) { this.username = username; };

 publicvoid setPassword(String password) { this.password = password; };

 publicvoid setPassword2(String password) { this.password2 = password; };

}

该javabean有3个field属性，分别是username用户名，password密码和password2验证密码。

接着写控制处理逻辑RegisterAction。代码如下：

package app;

import org.apache.struts.action.*;

import javax.servlet.http.*;

import java.io.*;

publicclass RegisterAction extends Action {

 public ActionForward perform(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) {

    RegisterForm rf = (RegisterForm) form;

    String username = rf.getUsername();

    String password = rf.getPassword();

    String password2 = rf.getPassword2();

    if (password.equals(password2)) {

        return mapping.findForward("success");

    }

    return mapping.findForward("failure");

 }

}

通过form表单读入数据，如果密码和验证密码相同，那么就跳到success，否则是failure，这个逻辑非常简单。Struts中也看不出任何的velocity相关（那当然，这就叫低耦合，各干各的，分层处理）

然后该配置熟悉的struts-config.xml了。核心代码如下：

<struts-config>

<form-beans>

<form-bean name="registerForm" type="RegisterForm"/>

</form-beans>

<action-mappings>

<action path="/struts"

type="RegisterAction"

name="registerForm">

<forward name="success" path="/success.vm"/>

<forward name="failure" path="/failure.vm"/>

</action>

</action-mappings>

</struts-config>

配置文件与传统的struts出奇的一致，唯一变化的就是在forward里的path写成了vm文件，而不是我们传统的jsp。

好了，写到现在，MVC中的M和C都完成了，该是velocity上场了——View层。

注册页面register.vm的核心代码：

<form action="struts.do" method="post">

 username: <input type="text" name="username"/><BR>

 password: <input type="text" name="password"/><BR>

 again   : <input type="text" name="password2"/><BR>

<input type="submit" name="submit" value="Register"/>

</form>

Success跳转页面success.vm：

<HTML>

<HEAD>

 <TITLE>Success</TITLE>

</HEAD>

<BODY>

 Registration Success!

 Thanks for logging in $!registerForm.username

 <P><A href="register.vm">Try Another?</A></P>

</BODY>

</HTML>

其中只用到了一个$!registerForm.username。整个代码完成了，压根没用到什么context之类的东西。

源代码来自http://www.wiley.com//legacy/compbooks/gradecki/apache/index.html

Spring基础学习注记

Spring是轻量级的，AOP的，DI的，框架的，容器的

轻量级：体积（2.5M），开销

DI：通过DI来松耦。所谓依赖注入，即组件之间的依赖关系由容器在运行期决定，形象的来说，即由容器动态的将某种依赖关系注入到组件之中

AOP：理解为“切面”比较合适，AOP则是针对业务处理过程中的切面进行提取，它所面对的是处理过程中的某个步骤或阶段，以获得逻辑过程中各部分之间低耦合性的隔离效果。OOD/OOP面向名词领域，AOP面向动词领域。AOP还有另外一个重要特点：源码组成无关性。

容器的：负责AO的lifecycle和configuration。可以定义AO如何被创建、如何配置和如何相互关联。

框架：配置和组合应用，管理AO，通过XML配置，并提供很多基础设施服务，比如事务管理，持久化框架集成。

Spring’s core container：提供基本功能，包括BeanFactory（DI的基础，spring框架的基础）。

Application context module：core使spring像个容器，而context则使其像一个框架。常用的一个应用就是集成velocity和freemarker的一个集成点。

Spring’s AOP module：顾名思义。

JDBC abstraction and the DAO module：集成数据库操作。这个模块会利用AOP模块提供的事务管理功能。

Object-relational mapping (ORM) integration module：在DAO的基础上提供ORM的solution。Spring不实现自己的ORM，只是提供一个与ORM框架结合的接口，比如Hibernate，JPA,JDO,IBATIS等。同样spring的事务管理也与这些框架相结合。

Java Management Extensions (JMX)：Exposing the inner workings of a Java application for management is a critical part of making an application production ready. Spring’s JMX module makes it easy to expose your application’s beans as JMX MBeans. This makes it possible to monitor and reconfigure a running application.

Java EE Connector API (JCA)

The enterprise application landscape is littered with a mishmash of applications

running on an array of disparate servers and platforms. Integrating these applications

can be tricky. The Java EE Connection API (better known as JCA) provides a

standard way of integrating Java applications with a variety of enterprise information

systems, including mainframes and databases.

In many ways, JCA is much like JDBC, except where JDBC is focused on database

access, JCA is a more general-purpose API connecting to legacy systems. Spring’s

support for JCA is similar to its JDBC support, abstracting away JCA’s boilerplate

code into templates.

The Spring MVC framework

与ORM不同，MVC模块既结合已有的像Struts、Tapestry、WebWork这样的框架，也提供了自己的MVC框架。

Spring Portlet MVC

Many web applications are page based—that is, each request to the application

results in a completely new page being displayed. Each page typically presents a

specific piece of information or prompts the user with a specific form. In contrast,

portlet-based applications aggregate several bits of functionality on a single web

page. This provides a view into several applications at once.

If you’re building portlet-enabled applications, you’ll certainly want to look at

Spring’s Portlet MVC framework. Spring Portlet MVC builds on Spring MVC to provide

a set of controllers that support Java’s portlet API.

Spring’s web module

提供MVC模块需要的classes。

Remoting

Not all applications work alone. Oftentimes, it’s necessary for an application to

leverage the functionality of another application to get its work done. When the

other application is accessed over the network, some form of remoting is used

for communication.

Spring’s remoting support enables you to expose the functionality of your Java

objects as remote objects. Or if you need to access objects remotely, the remoting

module also makes simple work of wiring remote objects into your application as

if they were local POJOs. Several remoting options are available, including

Remote Method Invocation (RMI), Hessian, Burlap, JAX-RPC, and Spring’s own

HTTP Invoker.

Java Message Service (JMS)

The downside to remoting is that it depends on network reliability and that both

ends of the communication be available. Message-oriented communication, on

the other hand, is more reliable and guarantees delivery of messages, even if the

network and endpoints are unreliable.

Spring’s Java Message Service (JMS) module helps you send messages to JMS

message queues and topics. At the same time, this module also helps you create message-driven POJOs that are capable of consuming asynchronous messages.

解释一个spring的xml：

<beans>是根元素。

<bean>告诉容器如何配置一个class，id属性表示这个bean对象的名字，class属性表示这个bean对象的具体class。

<bean>下的<property>用于设置一个该bean对象的属性property，name属性表示这个property的名字，value属性传递给这个property值。用property这种方式，等同于利用bean对象的set方法。

<bean>下的<constructor-arg>与<property>类似，只是这个等同于利用bean对象的赋值构造函数。

粗解DI

The key benefit of DI is loose coupling.

Interface programming

通过配置文件xml，写beanfactory等，来实现简单注入，从而松耦。

粗解AOP

解释aop的xml配置元素：

<aop:config>解释要做aop配置，是spring aop基本必备的元素

——<aop:aspect>表示声明一个aspect，这个aspect的功能被定义在其ref属性中，ref一般会联系一个已经定义好的bean对象。一个aspect由pointcuts（功能在哪里实现）和advice（功能怎样实现）组成。

————<aop:pointcut>定义一个pointcut，触发条件是某方法被执行。

————<aop:before>顾名思义，一个advice

————<aop:after>同上。

Basic bean wiring

The act of creating these associations between application objects is the

essence of dependency injection (DI) and is commonly referred to as wiring.

Spring container

BeanFactory

顾名思义，遵循工厂模式的一个类，管理和分发beans。

通用的工厂，可以管理分发各种类型的beans。

Beanfactory参与了bean的整个生命周期。

多种实现方式，最常用的是org.springframework.beans.factory.xml.XmlBeanFactory，通过加载xml来实现。当然必须要传递一个Resource给beanfactory。例：BeanFactory factory = new XmlBeanFactory(new FileSystemResource("c:/beans.xml"));

得到一个bean的方法就是调用getBean()。比如：MyBean myBean = (MyBean) factory.getBean("myBean");

application context

等同于beanfactory，但是提供more：

1． 支持I18N的消息

2． 提供一般基本方法去加载file resources

3． 发布events到已经注册为listener的beans

ClassPathXmlApplicationContext和FileSystemXmlApplicationContext比较常用。例：ApplicationContext context = new FileSystemXmlApplicationContext("c:/foo.xml"); ApplicationContext context = new ClassPathXmlApplicationContext("foo.xml");

bean’s life

Creating Beans

分两步，首先声明一个bean，即定义一个类。然后注入，即为其注入属性内容。

何时选择setter注入，何时选择constructor注入，见spring in action原书第45页。

Injecting into bean properties

通过<property>元素完成注入。其等价于调用bean对应类的setXXX方法。

例：<property name="song" value="Jingle Bells" />

其中value的值，spring会根据property的具体类别来选择不同的数据类型。

<property name="instrument" ref="saxophone" />这样的声明中，表示该property是一个类的对象，其类就是已经声明过的某个bean：saxophone。

在<property>下直接定义bean叫做inner bean。（当然通过constructor道理相同）

对于复杂集合类型：

其中的map需要注意一下。Props的代码实现上与map也不同。

Autowiring

The four types of autowiring

byName：找到name相匹配的，wire

byType：找到type匹配的，wire

constructor：利用constructor参数匹配，wire

autodetect：先constructor，再byType

Controlling bean creation

有多少对象实例，就由多少bean

从静态的工厂去构造bean，而不是constructor

构造好bean后要及时初始化，在bean销毁之前要及时clean up

Bean scoping

所有的spring beans都是单例的。

通过设置<bean>的scope=”prototype”，spring可以在需要的时候产生新的bean的实例。

Initializing and destroying beans

<bean>中有init-method和destroy-method负责设置初始化和销毁时调用的方法。

如果很多bean都有同样的初始化和销毁程序，那么可以在<beans>中设置defaultinit-

method 和 default-destroy-method

还有种方法就是bean类的定义时，让类去实现InitializingBean 和DisposableBean.

Advising beans

重点讲述AOP。

Introducing AOP

Aspect帮助我们建模那些cross-cutting concerns（一个应用中在多个位置起到作用的点，比如security）。

Defining AOP terminology

AOP一般用advice、pointcut和joinpoint描述。

Advice：aspect必定是在做一个job，即要做某个功能。其中这个job就叫做advice。Advice定义了aspect的what和when。

Joinpoint：在整个application中有可能用到advice的连接点。

Pointcut：定义了aspect的where。

Aspect：是advice和pointcut的merger。

Spring’s AOP support

Spring支持4种风格的aop：

Spring的advice都是java写的。

Spring在运行时advise object。

Spring只支持方法连接点method joinpoint。

Spring MVC

其中，一个command object 就是一个像struts中的actionform一样的东西。

Wizard是一个可以将多个页面联合起来作为一个form的东西。


基本搞完了，总的来讲，学习的东西就要经常用，否则慢慢的就会淡忘了，尤其是技术上的一些细节。如果没遇到类似的问题，是很难记忆深刻的~~~

 1/** *//**
 2 * 
 3 */
 4import java.io.*;
 5import java.util.*;
 6
 7import org.ahmadsoft.ropes.*;
 8
 9/** *//**
10 * @author Jia Yu
11 * @date 2010-1-25
12 */
13public class Test2 {
14
15    /** *//**
16     * @param args
17     */
18    public static void main(String[] args) {
19        // TODO Auto-generated method stub
20
21        int max = 100000;
22        String eq = "";
23        Rope r = Rope.BUILDER.build("");
24        StringBuffer sb = new StringBuffer("");
25        StringBuilder sb2 = new StringBuilder("");
26
27        double st = System.nanoTime();
28        for (int i = 0; i < max; i++) {
29            eq += "h";
30        }
31        double ed = System.nanoTime();
32        System.out.println(ed - st);
33
34        st = System.nanoTime();
35        for (int i = 0; i < max; i++) {
36            sb.append("h");
37            // sb.deleteCharAt(0);
38        }
39        ed = System.nanoTime();
40        System.out.println((double) ed - (double) st);
41
42        st = System.nanoTime();
43        for (int i = 0; i < max; i++) {
44            sb2.append("h");
45            // sb2.deleteCharAt(0);
46        }
47        ed = System.nanoTime();
48        System.out.println((double) ed - (double) st);
49
50        st = System.nanoTime();
51        for (int i = 0; i < max; i++) {
52            r.append("h");
53        }
54        ed = System.nanoTime();
55        System.out.println((double) ed - (double) st);
56    }
57}
58

结果如下：
1.6120785922E10
1.0273193E7
2647639.0
9781992.0
只从数量级比较的话，String的低效就不说了，毕竟基于Char[]实现的，而StringBuffer比StringBuilder慢也可以理解，毕竟加入了同步的考虑，也算是为线程安全付出的代价，但是所谓的树型机制的Rope还是比不过StringBuilder啊~~~

Rope for Java 下载：点击这里。
这里附加了文章中的测试代码：点击这里。