银翼杀手
2049没好人。
JVM 与编译优化
Java 的编译分期，至少可以分为两个阶段（有些情况下还有额外的第三种编译过程）： 编译前端（前端编译）：把 *.java 变成 *.class 文件的过程。也就是把源语言文件变成中间语言文件的过程。典型的例子有：javac、Eclipse 的 ECJ 的工作过程。 编译后端（后端编译）：由 JIT（Just In Time Compiler）把中间语言（字节码）转换成二进制目标体系结构机器码的过程。典型的例子有 HotSpot 的 C1、C2 编译器的工作过程。 AOT（Ahead Of Time）编译器直接把源代码编译成二进制目标体系结构机器码的过程。 早期（编译）优化 javac 自从 1.3 版本已经不再支持 -O 的优化了。所有的优化策略集中到后端编译里。这样没有经过 javac 编译的 JRuby、Jython 程序，也可以享受到 JVM 的优化福利。 javac的编译过程，大致上是： 解析和填充符号表（Parse and Enter）。 注解处理（Annotation Processing，Java 5以后加入的过程）。 分析与字节码生成（Analyze an...
基于栈的虚拟机
基于栈的虚拟机 全景导图 mindmap root((基于栈的虚拟机)) 核心架构 操作数栈 局部变量表 栈帧 执行机制 字节码指令 基于栈的运算 指令集简洁性 设计优势 可移植性 代码紧凑 实现简单 典型应用 JVM Python虚拟机 .NET CLR 模式总览 # 模式名称 一句话口诀 覆盖场景 1 栈式计算 数据流与控制流分离，操作数隐式传递 JVM字节码执行、表达式求值、递归调用 2 栈帧隔离 每个方法调用独立的执行上下文 方法调用、异常处理、线程隔离 3 指令紧凑 操作数位置编码在指令中，减少指令长度 字节码压缩、跨平台分发 问题定义 为什么选择基于栈的虚拟机架构，而非基于寄存器的架构？这种设计如何影响字节码的生成、执行效率以及跨平台可移植性？ 核心概念 虚拟机架构分类 虚拟机按照指令集架构主要分为两类： 基于栈的虚拟机：指令不指定操作数的位置，操作数从栈顶弹出...
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以上，却不能用8.x。npm 也有特别的版本要求： npm install npm@3.10.10 -g 要用...
思考区块链
区块链是比特币的基础设施。由区块组成链，是为区块链。各个区块链的持有者之间，总是在玩不确定选主的游戏，所以这和所有传统的分布式数据库不同，是一个去中心的数据存储模式。 比特币的区块链是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虚拟机是如何处理异常的》，深入地分析了 JVM 对异常跳转的处理过程：JVM 会通过异常表的机制，优化异常抛出和正常返回之间的性能差异。仅从程序计数器的移动上来讲，抛出一个异常对栈帧的弹栈并不比直接返回更昂贵。写在前头的结论是："try-catch 语句块几乎不会影响程序运行性能！...
大明朝里没好人
大明朝里无好人。这篇文主要写写杨幂。
过零丁洋
倒叙把完整的段落裁剪开来，突显了拼接的价值。观众心中的悬念一得解脱，戏剧高潮就放大了。诺兰以往的片子，多层次的叙事构成了宏大的立体结构，也使得故事有了深邃的思考空间。 但是，《敦刻尔克》却是灵性全无，扬短避长的片子。 影片的前中半部充满了刻意的剪切，一直都在追亡逐北的急剧压迫感中度过，不断堆积观众的焦虑感，让人失去耐性。战争永远是荒谬的。《神奇女侠》虽然烂，但导演还知道要穿插几场文戏，让人思考个人、集体与战争的矛盾关系。更不用说《拯救大兵瑞恩》夜晚的对谈，导演借战士之口向观众口述人性的矛盾。诺兰不知道是不是有意拒绝平庸套路，把战争的煎熬一再翻炒，别的什么都不拍，观众在联军的狼狈里饱尝炼狱感，大晕其浪。以至于后来长空翰海一机划破夕阳和百船破浪，变成了功能性的高潮。观众看得长舒一口气，这场逃亡终于结束了，这个冗长的结构走到了尽头。 历史上的敦刻尔克大逃亡里，出现过很多毫不逊色于电影镜头的英勇作战场面。德军装甲师与空军，法国的陆军和英国的空军进行激烈交锋，敦刻尔克的逃亡空间可谓用无数尸体铺出的血路。而诺兰为了突出逃亡的仓皇，放弃了全局的观察视角，只是局促于海滩一隅。这部电影最讨厌的部分...
