我们都知道在Java语言规范已经规定了int的大小是4个字节，那么Integer对象的大小是多少呢？要知道一个对象的大小，那么必须需要知道对象在虚拟机中的结构是怎样的，来看看Hotspot中对象在内存中的结构：

从上面的这张图里面可以看出，对象在内存中的结构主要包含以下几个部分：

• Mark Word：对象的Mark Word部分占4个字节，其内容是一系列的标记位，比如轻量级锁的标记位，偏向锁标记位等等。
• Class对象指针：Class对象指针的大小也是4个字节，其指向的位置是对象对应的Class对象（其对应的元数据对象）的内存地址
• 对象实际数据：这里面包括了对象的所有成员变量，其大小由各个成员变量的大小决定，比如：byte和boolean是1个字节，short和char是2个字节，int和float是4个字节，long和double是8个字节，reference是4个字节
• 对齐：最后一部分是对齐填充的字节，按8个字节填充。

根据上面的图，那么我们可以得出Integer的对象的结构如下：

Integer只有一个int类型的成员变量value，所以其对象实际数据部分的大小是4个字节，然后再在后面填充4个字节达到8字节的对齐，所以可以得出Integer对象的大小是16个字节。

因此，我们可以得出Integer对象的大小是原生的int类型的4倍。

关于对象的内存结构，需要注意数组的内存结构和普通对象的内存结构稍微不同，因为数据有一个长度length字段，所以在对象头后面还多了一个int类型的length字段，占4个字节，接下来才是数组中的数据，如下图：

关于对象内存布局更多的内容，可以看这篇文章：Java Objects Memory Structure

网上看了下这个问题的大致解决方法有两个：一个是Root掉Nook；另一个往epub文件中塞入一段CSS，再在Nook中看的时候只需要选择Publisher Defaults就可以正常显示中文。

第一个方法风险太高，可能导致Nook变砖；

第二个方法的话可以用Calibre之类的工具来完成，但是Calibre这个东西本身太重了，每次打开关闭很耗时间，UI又丑，实在不想用。

所以，我需要一个命令行的工具来完成往epub中塞入一段CSS这个任务，这样可以和*nix下的其他工具结合起来使用，检测一个文件夹中如果新加入了epub文件，就直接进行转换，让整个过程完全自动化。现在这个命令行工具就是Varamyr（Varamyr是马丁大爷的冰与火之歌的第五部《魔龙的狂舞》序言里面的一个狼灵，打酱油的角色。）

运行Varamyr你需要

1. JRE环境
2. *nix系统，不支持windows也不会支持windows
3. 下载varamyr.jar

如何使用？

1. 运行命令：java -jar varamyr.jar <path-to-epub-file>，<path-to-epub-file>为你需要修改的epub文件的路径
2. 看看在你修改的epub文件的路径下是不是多了一个类似xxxx-varamyr.epub的文件。

源代码 & 原理

• 源代码放在github上了：https://github.com/khotyn/Varamyr
• 原理很简单，不用讲了，直接看源代码吧。

拿到手以后首先是外包装，白色，很小，右上角有一个THE ALL NEW NOOK的字样，表示是全新的Nook，而不是官翻的机子。

打开包装以后里面是就一只Nook和一个USB的连接线，没有其他配件了。首次使用需要充足够的电才能够开机。

充电中，虽然屏幕上写着要等15分钟，但是实际上要差不多1个小时。等冲到了足够的电Nook会自己启动，然后就是一堆设置，连接上Wifi去激活Nook。

看看背面，Nook的开关键在背后，背面的中间是凹进去的，握起来比较舒服。

现在来看看Nook看书的效果到底如何吧：

这个是看英文的epub格式的电子书的照片，可以看到英文字体效果还是非常不错的。

这张是看中文的epub格式的电子书，非常坑爹，直接显示方块了，Nook原生并不支持中文，需要用Root的方式去解决。

然后是英文的pdf，可以看到Nook已经对pdf的文字进行了重新排列，以适合Nook的显示大小。

最后是中文的pdf，看起来效果也还可以。

另外再讲讲操作体验，Nook是红外线触摸屏的，触摸屏的体验非常不错，翻页非常灵敏，触摸屏用来查单词也是非常方便，只要点住单词即可，除了触摸屏以外，Nook在左右两边还提供了4个翻页键，但是遗憾的是按起来需要用点力，感觉不是很好。

屏幕的显示方面，效果还马马虎虎，因为Nook 2采用的是局部刷新，翻了6页以后才全刷，所以翻页后可以看到一些残影，这个非常让人不爽，不知道有没有什么办法可以解决这个问题。

至于和Kindle比较哪个好，哪个差，我也说不上来，总体来说，Nook 2还算是令人满意吧，如果你也要买一个电子书，不妨页考虑下Nook。

然后我又拿起了《禅与摩托车维修艺术》(即：《万里任禅游》)，奇怪的是看这本书的时候心情总是很平静，也许是从来没有打算在什么时候看完它。刚翻到第二部分，突然又想起了这本书中的一句话：

仓促本身就是20世纪最要不得的态度，当你做某件事的时候，一旦想要求快，就表示你再也不关心它，而想去做别的事。

的确，现在信息的获取速度越来越快，结果却把使人们变得越来越不耐烦，越来越没有耐心去做一件事情，也越来越没有耐心去等待一件事情的结果。

信息时代不仅仅加速了信息获取的方式，也加速地消耗着人们的耐心。所以在这个快速的世界里，我想最重要心态是慢。慢不是囫囵吞枣地去做一件事情，也不是对这件是事情无所谓，三天打鱼，两天晒网，慢是从容，从容地把一件事情做好，做完美，虽然这个世界上没有完美的事情，但是当把一件事情做到接近完美的事情，意想不到的事情就会发生。

说到这里，便想起了那部昨天导致我晚睡的电影《时间规划局》，里面的“时间穷人”因为剩余时间总是不多，所以总是行色匆匆。而”时间富人”因为时间总是很充足，所以步调总是比较慢，也比较从容。想想我们的时代，我们的时间并没有科技的发展而流逝地更快，或者流逝的更慢。相对于以前，因为科技的成就，我们做一件事情的时间也更加充裕，我们应该更加从容地去做事情，而不应该更加急迫。

所以，切记切记，慢慢来，不必着急，不知不觉你可以走得比别人更远。

What’s New?

• 选项页面有了新UI，如上图。
• 规则的添加和显示集成到了一起。
• 去除了规则到处功能，让插件更小巧。

下载：Slash-to-Search

正则表达式的语法

对于正则表达式的语法，相信大多数人都和我一样知道一些基本的语法，但是对于一些不常见的语法还是非常陌生，这边就把这些比较陌生的正则表达式语法记录一下：

• 分组且捕获的文本括号：()，文本被捕获以后可以通过反向引用（\1，\2等等）来引用。
• 分组但是不捕获的文本括号：(?:)，文本被捕获后不能通过反向引用来引用到。
• 忽略优先量词：*?，+?，??，{min,max}?：量词在正常情况下是“匹配优先”的，会尽量匹配更多的内容（Greedy），忽略优先量词则优先匹配尽量少的内容。
• 占有优先量词：?+，*+，++，{m,n}+，与匹配优先量词很相似，只是从来不交还已经匹配的字符，即如果已经匹配到了，就放弃该量词表达式内的所有的回溯可能都抛弃。
• 固化分组：(?>…)，使用固化分组的匹配与正常的匹配无差别，但是如果匹配进行到此结构之后，那么此结构体中所有的备用状态都会被放弃。占有优先量词可以看做是固化分组的特殊情况。
• 条件判断：(?if then|else)：测试if条件表达式，如果测试为真，则执行then部分表达式，如果测试失败，则执行else部分表达式，if条件表达式是特殊的表达式，大概有两种情况，一种是对捕获型括号的特殊引用，比如(?(1))这样，会测试第一组捕获型括号是否参与了匹配；另一种是对环视进行匹配，如果环视能够匹配，则返回true。
• 环视，即零宽断言：(?=…) (?!…) (?<=…) (?<!…)，具体的解释可以参考我之前关于零宽断言的一篇文章：使用零宽断言来匹配不包含连续字符串的行。
• 匹配上一次匹配结束的位置：\G，首先出现在Perl中，在用于迭代匹配的时候比较有用。

正则表达式引擎的工作原理

一般上正则表达式的引擎可以分为两种：NFA和DFA，分别表示非确定性有穷自动机和确定性有穷自动机，这两者背后的理论基础大可不必去了解，只需要知道NFA引擎是在进行匹配的时候是表达式主导的，而DFA引擎在进行匹配的时候是文本主导的，下面具体来拿一个例子来将述下这两者的区别：

NFA引擎工作原理

对于NFA引擎，它会先拿出正则表达式的第一部分，然后看看文本有没有符合这个部分的，如果是，则继续表达式的下一部分进行匹配。

现在假设我们有一个正则表达式是a+b，需要用它去匹配aaaaab这个字符串，它的匹配过程大概如下：

1. 首先找到正则表达式的第一个部分a+
2. 然后看文本是否匹配到了这个表达式，在文本中，前面的5个a是能够匹配a+的，那么继续正则表达式的下面部分
3. 后面是一个b，它能够匹配到文本中5个a后面的b，也匹配成功。
4. 这样正则表达式的所有部分都能够匹配，所以整个表达式就能够匹配成功。

NFA引擎还有一个重要的特性，这个特性对于理解NFA引擎的原理也是非常关键：回溯。具体来就讲，在遇到两个可能成功的分支时，会先尝试一个可能性，然后记住另一个，如果这个可能性失败了，那么就回溯到之前的可能，回溯的一个重要的原则是，如果需要在“进行尝试”和“跳过尝试”之间选择，对于匹配优先量词，引擎会优先选择“进行尝试”，对于忽略优先量词，引擎会优先选择“跳过尝试”；在进行回溯时，选择回溯的路径是距离最近存储的路径，即基于LIFO原则。

DFA引擎工作原理

对于DFA引擎，DFA引擎会在扫描子字符串时，记录当前有效的所有可能匹配。这个我们就拿书中的tonight的例子来讲。

现在我们拿to(nite|knight|night)来匹配tonight，它的匹配过程大致如下：

1. 引擎看拿到文本中的t，然后找到了表达式中的t可以与之匹配，这样，表达式就可能能够匹配到文本，这样引擎就会添加这样一种潜在的可能。
2. 然后引擎继续按照文本往下移动到了n，这个时候，表达式的多选分支里面只有两个分支可以与之匹配，knight这个分支不能匹配，有效的可能就变成了两个。
3. 继续往下走到文本中的g，这个nite这个分支也不能匹配了，有效的可能变成了一个。
4. 最后当匹配到之后的t时，night这个分支显然能够匹配，这样引擎发现匹配已经成功。

NFA引擎和DFA引擎的各自优缺点：

• 从上面的讲解中可以了解到，NFA引擎因为是正则表达式主导的，可能对文本中的同一个部分进行反复的扫描，DFA则只会对文本进行一次扫描，这样NFA引擎的速度就相对DFA要慢。
• 另外NFA是正则表达式主导的，所以不同的正则表达式对速度的影响比较大，但是DFA因为是文本主导，所以不同的正则表达式对其速度影响不大。
• 从上面一条我们也可以知道，NFA的可玩性就比较大了，相对来说比DFA要灵活很多。其实后面的调优也都是针对NFA引擎的，因为DFA实在是没有什么好调优。

正则表达式调优

正则表达式的调优是在了解了正则表达式的工作原理的基础上进行的，主要是针对NFA引擎，看完正则表达式的调优这一章以后，我自己总结了一条调优的规律：在正则表达式中尽量使用确定的字符：

比较(night|nite|nittt|niasdf)和ni(ght|te|ttt|asdf)这两个正则表达式，因为后面一个正则表达式把各个多选分支中的ni提出来了，这样引擎就能够通过字符扫描的方式快速找到匹配文本中的ni部分，然后再开始匹配后面的多选分支；而前面的那个表达式，引擎在文本的每一个位置都要尝试四个分支，显然速度要慢很多。相比而言，后一个正则表达式比前一个要“确定”，匹配的速度就更快。

针对这一条规律，还可以有很多调优的方式，比如能够加锚点就加锚点之类的，具体的大家可以翻看书的第六章。

总结

应该说这本书觉得是一本值得阅读的书，花时间去看绝对是值得的，特别是当你会一点正则表达式后再去看，收获可能更大。不过这书的翻译看起来有点吃力，读起来不是很顺畅，或许是因为正则表达式本身看起来就有点累，所以看这本书的过程中最好保持头脑清醒，保持注意力集中，这样才能跟上作者的思路。

什么是内存屏障

内存屏障，说白了就是一个指令，其作用正如其名字里面所描述的，起到的是屏障的作用，具体地来说，内存屏障这条指令的作用是让屏障指令前面的指令不会被重排序到屏障指令之后，屏障指令之后的指令也不会被重排序到屏障指令之前，相当于一道屏障挡在了指令之间，前面和后面的指令都不能跨过屏障（关于指令重排序，这里不再解释，有兴趣了解的可以去Google一下）。

内存屏障的种类

鉴于CPU和编译器都可能对指令进行重排序，所以我将内存屏障分为两种：

• 编译器级别的：防止编译器对指令进行重排序，例如GCC的asm volatile("" ::: "memory")等等。
• 处理器级别的：防止处理器对指令进行重排序，例如X86的lock，lfence()，sfenec()等等(关于处理器级别的内存屏障如何实现，可以参考这篇文章)。

Java的volatile如何通过内存屏障保证其语义的：

首先，需要知道Java中的volatile有两个语义：

• 线程对volatile变量的读写都会马上反映到主存上，对其他线程马上可见。
• 对volatile变量的读写操作不会和其他对共享内存进行操作的指令重排序。

跟踪HotSpot JVM中对volatile的变量的写操作可以发现，其在写操作之后插入了一条指令

asm volatile ("lock; addl $0,0(%%esp)" ::: "cc", "memory");

我们可以把这个指令分成两部分来看：

• asm volatile ("" ::: "memory")：这个是GCC中常用的编译器级别的内存屏障，首先这是一条汇编指令，加入了volatile表示指令不会被重排，后面的clobber list里面加入了”memory”表示告诉编译器，指令对主存做了修改，所有CPU中的缓存都失效了，后面的指令需要重新从主存中重新Load数据。
• lock; addl $0,0(%%esp)：对于这一条指令，首先看addl $0,0(%%esp)这个部分，这个部分实际上是个无用操作，如果esp栈顶是0的话，就给栈顶加上一个0，由于这个操作会影响到程序状态字寄存器，所以在后面的clobber list中加入了cc(Condition Code Registry,也称为Flag Registry或Programm Status Word Registry)；再看这个汇编指令前面加入了一个lock前缀，这个lock前缀的意思是执行指令的CPU会发出LOCK#信号，独占系统主线直到前面的读写操作全部完成并且执行完加了lock前缀的这条指令，在这个过程中其他CPU的读写操作全部被Hold住(参考Intel的开发手册)。所以lock前缀实际上可以看作是一个多处理器的内存屏障。

这两个部分合起来就起到了一个完整的内存屏障，即对编译器有效，也对处理器有效，另外也保证了volatile的可见性问题。

周六从杭州到苏州的路上走地匆匆，边找路，边赶路，在乌镇的时候还碰上@Trinea的车爆胎，耽搁了一点时间。赶到吴江防护林的时候，夜色已经悄悄降临，看到一轮明月从林间升起，才想起早上刚刚在新闻里面看到说今天有月全食，兴奋不已，随即在林字里停了一会儿，小桥，人家，明月，桥下流水，流水中的月影，看到这幅风景，便觉得不虚此行。不过没有单反相机，同行的几位也没有带单反，不能留下那一时的美，甚为遗憾。

到了吴江南北快速干线上的时候，月食开始，一路追着月亮骑过去，看月亮慢慢从盈变缺，几个小时便看到了月的阴晴圆缺，只怕之后再也看不到这样的景色，可惜的是等到月全食完全发生，我们已经到了市区，忙着找旅店，找填肚子的地方，没有看到红月。

有了第一天的经历，第二天从苏州回杭州便觉得轻松了很多，特地在吴江防护林停了一下，掏出手机拍了几张照片：

一直都呆在办公室里面，或者宅在家里，整个秋天就这样晃荡着过了，在初冬看到这样的红叶也算是对秋天的告别：

这张是@woodcafe拍的，吴江防护林里面有蛮多这样的风景，路左右的树连成了一片：

过了吴江防护林，很快便到了浙江境内，也就是乌镇，在乌镇的一座桥上偶遇落日，刚好一条运沙船从桥下穿过，也是很久没有见过的美景：

今年已经快要结束了，应该不会再出去骑车了，明年希望能够和不同的人出去骑车，到不同的地方去，看不同的风景，遇上不同的故事，这样才有意思，不是吗？

另：@woodcafe准备这个春节去环海南岛，大概要花上十天左右，我没有这么多时间可以用，去不成，只能在这里祝顺利了。

昨天晚上看海伯利安看到凌晨一点半，终于把最后一个故事给看完了。海伯利安绝对是我迄今为止看到的最好看的科幻小说，甚至比刘慈欣的三体系列，阿西莫夫的基地系列都要精彩很多。

海伯利安这个书名取自英国诗人约翰·济慈未完成的同名长诗海伯利安，整本书的内容是七个不同职业的人被选择作为最后一批朝圣者前往伯劳鸟和光阴冢所在的偏远星球海伯利安朝圣，他们在朝圣的途中讲述了各自背后沉痛的故事，以及各自和伯劳鸟、光阴冢之间的丝丝联系。

通过朝圣者们的故事，作者也给我们描述了故事发生的宏大背景，地球灭亡，人类将其活动范围扩大到了银河系跨度1000光年的小旋臂内，人类政府霸主组成环网星球，霸主背后又有神秘的人工智能，以及在太空中飘荡的人类分支驱逐者。

作为朝圣的目的地以及联系朝圣者们的线索，伯劳鸟和光阴冢应该是整本书中最神秘的东西了，但是看到最后，我仍然无法搞懂这两者到底是什么？牧师的十字形到底什么？战士的情人莫尼塔到底是不是就是伯劳鸟？诗人的海伯利安诗篇讲述的到底是什么？学者的女儿为什么受到时间潮汐影响后时间是倒着走的？侦探的情人之前到底为什么要去海伯利安朝圣？领事打开光阴冢后会发生什么？而那个没有讲述自己故事的圣徒背后到底又有什么样沉痛的故事？

除了书名取自济慈的长诗海伯利安以外，本书中还有非常多的关于济慈的东西，海伯利安的后续安迪密恩(Endymion)的名字也是取自济慈的同名长诗，故事发生的星球名字叫海伯利安，朝圣者中的侦探的赛伯人情人甚至就是人工智能造出来重现济慈的生活的，不得不说，整本书就是作者丹·西蒙斯在向济慈致敬。

除了济慈，你还能够在书中看到乔叟、叶芝等人的身影，经常能够看到一些名家出现在本书中，让你不得不感慨下作者的博学。

无疑，海伯利安是科幻小说中的史诗巨作，作为科幻迷的你千万不要错过。

JVM规范中一块很重要的地方就是内存的管理，JVM规范里面在功能上对JVM的内存进行了一定的划分，理解这一块内容对理解JVM的规范有一定的帮助。当然，就像许多规范一样，JVM规范虽然对内存进行了划分，但是各个JVM的实现却不一定会做这样的划分，说地确切一点是负责对应功能的内存肯定在每一个JVM的实现里面都是有的（如果没有提供参数给程序员调整的话，有些对你来说就是不可见的），但是其实现方式可以是五花八门的。另外，JVM对内存的分配和管理事实上是和Java Class文件的格式，JVM的运行机制都有密切相关，如果对这些东西有所了解，那么对内存的管理理解也会有所帮助。

先来看一张图来直观地感受下JVM规范里面是怎样对JVM的内存进行功能上的区分的：

在这张图里面，首先根据内存是线程私有的还是线程共享的，把内存区域分成了两块：

线程私有

这一块区域主要由程序计数器（PC），虚拟机栈（Virtual Machine Stack）和本地方法栈（Native Method Stack）组成

• 程序计数器：同计算机的程序计数器；如果正在执行Java方法，则指向虚拟机字节码指令的地址，如果是native的，这个计算器的值为空。
• 虚拟机栈：虚拟机栈是和线程的生命周期相同的，每创建一个线程，就会创建一个虚拟机栈。而在一个线程中，每调用一个方法，就会在虚拟机栈中创建一个栈帧（Stack Frame），用于保存方法相关的信息，栈帧的具体结构看上图的箭头左边部分：
  • 本地变量表（Local Variable）：用于保存本地变量，这里的本地变量是指方法的入参以及在方法中声明的变量，如果在编译Java文件的时候加上”-g”参数，然后用”javap -p -verbose”打印出class文件后可以看到一个方法的本地变量表的内容，下面是一个简单的“Hello, world!”程序的main方法的本地变量表：

    LocalVariableTable:
    Start  Length  Slot  Name   Signature
    0      9      0    args       [Ljava/lang/String;
    

  • 操作数栈（Operand Stack）：首先要了解JVM的架构是基于栈的指令集，指令的操作都是对栈的操作，所以方法运行的时候的一些参数和中间变量都必须先放入栈中才能够被操作，这里面的栈指的就是操作数栈，注意不要和前面提到的虚拟机栈混为一谈。
  • 对运行时常量池的引用（Runtime Constant Pool Reference）：这里面主要保存对在方法中调用的方法的符号引用，这些符号引用会在运行时被解析成对方法的真正引用。
• 本地方法栈：本地方法栈的功能和虚拟机栈的作用相同，不同的是本地方法栈服务的对象是本地方法。

线程共享

线程共享这一块区域说起来就一块东西：堆；稍微细分一下可以分为方法区（Method Area）和”存放类实例的区域”

• 方法区：主要存放已被虚拟机加载的类信息、常量、静态变量、即时编译器编译以后的代码，其中运行时常量池也在方法区中。
• “存放类实例的区域”：这一部分内存是存放对象，所有实例化的对象都会放在这个地方。

直接内存

前面看到的都是JVM的运行时数据区的部分，JVM的内存中还有另外一部分叫直接内存（Direct Memory，对应上面的图中的最下方的地方），它不是JVM运行时数据区的一部分，不受JVM的GC管理。其中Java NIO中的Buffer直接在堆外分配的就属于这个部分。