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