JVM 与编译优化
Java 的编译分期，至少可以分为两个阶段（有些情况下还有额外的第三种编译过程）： 编译前端（前端编译）：把*.java变成*.class文件的过程。也就是把源语言文件变成中间语言文件的过程。典型的例子有：javac、Eclipse 的 ECJ的工作过程。 编译后端（后端编译）：由 JIT（Just In Time Compiler。我认为应该还要把 Interpreter包括在内）把中间语言（字节码）转换成二进制目标体系结构机器码的过程。典型的例子有，HotSpot 的 C1，C2编译器的工作过程。 AOT（Ahead Of Time）编译器直接把源代码编译成转换成二进制目标体系结构机器码的过程。 早期（编译）优化javac 自从1.3版本已经不再支持什么 -O 的优化了。所有的优化策略集中到后端编译里。这样没有经过 javac 编译的 JRuby、Jython程序，也可以享受到 JVM 的优化福利。 javac的编译过程，大致上是： 解析和填充符号表（Parse and Enter）。 注解处理（Annotation Processing，Java 5以后加入的过程）。...
基于栈的虚拟机
基于栈的虚拟机，可移植性更好。
Hyperledger Fabric 网络的启动步骤
本文是截至日前（2017.10.27）时对官方教程和自我实验的重新梳理。 Hyperledger Fabric 可以说是 Hyperledger 的拳头项目。虽然同为 Apache 的顶级项目，但大部分其他项目都以 Fabric 为基础。它是顶级项目中的顶级项目，可以认为是0级项目。 docker 要有高于 17.06.2-ce 的版本。docker-compose 要有 1.14.0 及以上的版本。当然当前的高版本的 docker 已经自带了高版本的 docker-compose，这通常不用担心。 安装1.9+ 的 Golang。应该预期这样的结果： echo $GOPATH /Users/xxx/go 如果这个结果出不来，考虑当前 Shell 的环境变量没有正确设置： export GOPATH=$HOME/go export PATH=$PATH:$GOPATH/bin 要用一个很特别的 nodejs 版本。6.9以上，却不能...
思考区块链
区块链是比特币的基础设施。由区块组成链，是为区块链。各个区块链的持有者之间，总是在玩不确定选主的游戏，所以这和所有传统的分布式数据库不同，是一个去中心的数据存储模式。 比特币的区块链是1.0的玩法，以太坊是2.0的玩法。有些人认为 Hyperledger 是3.0的玩法，还有待怀疑。 区块链上的资产，可以是自带的（比特币网络里的比特币，以太坊网络里的以太币），也可以是智能合约定义和约束的。 智能合约是个看起来很美好，实际上只能执行在沙盒里面的东西。曾经在某个IBM程序员的分享里看到过，Hyperledger 的智能合约本质上也是 GO 程序，所以理论上可以做一切事情。但目前没有看到除了调用各种 Shim API 以外的任何用处。比如，如果我们想要用智能合约发出另外一个调用请求，让真实的系统发生转账，如何做到？ 很多人都有热思考，人类再也回不到没有比特币的时代了。也有冷思考，区块链的时代还未到来。就目前而言，现在的计算性能真的不足以支撑真实的行业流量，只能养养鸡，运运肉。 也有观点认为，公有链是真命题，而私有链是伪命题。就目前的观察看来，不管是 Hyperledger 还是 Co...
昂贵的异常
抛出问题 Joshua Bloch 在《Effective Java》的 Item 57 里明确地提到过，不要试图用 Exception 的跳转来代替正常的程序控制流。他列举了很多原因，但特别提到了抛出异常会使得整个程序运行变慢。抛出异常远比普通的 return , break 等操作对控制流、数据流的性能影响要大，它就只适合拿来作异常分支的控制语句，而不能拿来编写正常的逻辑。 Throwing exception is expensive. 这句话在 Java 的程序员世界里面已经成为老生常谈。却很少有人谈及，但到底抛出异常比正常的程序跳转返回慢在哪里，有多慢。“不要滥用异常”好像一个猴子定律，人们忘记了为什么不能这么做，却不明白为什么不能这么做。 这几天读了一位同事写的好文[《Java虚拟机是如何处理异常的》][2]，深入地分析了 JVM 对异常跳转的处理过程: JVM 会通过异常表的机制，优化异常抛出和正常返回之间的性能差异。仅从程序计数器的移动上来讲，抛出一个异常对栈帧的弹栈并不比直接返回更昂贵。写...
大明朝里没好人
大明朝里无好人。这篇文主要写写杨幂。
过零丁洋
倒叙把完整的段落裁剪开来，突显了拼接的价值。观众心中的悬念一得解脱，戏剧高潮就放大了。诺兰以往的片子，多层次的叙事构成了宏大的立体结构，也使得故事有了深邃的思考空间。 但是，《敦刻尔克》却是灵性全无，扬短避长的片子。 影片的前中半部充满了刻意的剪切，一直都在追亡逐北的急剧压迫感中度过，不断堆积观众的焦虑感，让人失去耐性。战争永远是荒谬的。《神奇女侠》虽然烂，但导演还知道要穿插几场文戏，让人思考个人、集体与战争的矛盾关系。更不用说《拯救大兵瑞恩》夜晚的对谈，导演借战士之口向观众口述人性的矛盾。诺兰不知道是不是有意拒绝平庸套路，把战争的煎熬一再翻炒，别的什么都不拍，观众在联军的狼狈里饱尝炼狱感，大晕其浪。以至于后来长空翰海一机划破夕阳和百船破浪，变成了功能性的高潮。观众看得长舒一口气，这场逃亡终于结束了，这个冗长的结构走到了尽头。 历史上的敦刻尔克大逃亡里，出现过很多毫不逊色于电影镜头的英勇作战场面。德军装甲师与空军，法国的陆军和英国的空军进行激烈交锋，敦刻尔克的逃亡空间可谓用无数尸体铺出的血路。而诺兰为了突出逃亡的仓皇，放弃了全局的观察视角，只是局促于海滩一隅。这部电影最讨厌的部分...
