血铸的真理，向来不惧墨写的谎

2025/08/31 读书

今日听到一则奇闻。

这日本外务省的官僚们伏在冷气森森的官邸里，捏着钢笔，绞着脑汁，在雪白的公文纸上爬出一行行外交辞令。

这辞令是极雅致的，裹着“区域稳定”“历史和解”的绸缎，内里却爬满虱子。翻来覆去无非就是劝导列国莫去观中国的“九三”阅兵仪式，莫看那沾血的纪念碑，莫听那震天的呐喊罢了。

嗨呀，东瀛的先生们大约是怕的。他们都在怕什么？怕那纪念碑上的名字太真切，怕那受难者的眼睛太亮，怕那阅兵的脚步声太齐整，踏碎了他们潜藏心底的军国旧梦。

于是慌忙扯起“反日煽动”的幡，仿佛受害者的控诉，与这对和平的纪念，反倒成了一种过错。这道理，倒像强盗闯入人家里，夺了财宝，杀了亲人，烧了房屋，还要那苦主闭口不言，否则便是“过度聚焦”，便是“煽动旧恨”。

我看那所谓辞令，字缝里渗出两个字：“心虚”。十五国使馆的急电，十五份烫金的劝诫，堆叠如一座新造的靖国牌坊。牌坊下跪着那帮穿西装的东瀛遗老遗少，一面细细的涂改着教科书里的“南京大屠杀”，“731部队”，一面又对着西洋老爷们打躬作揖：“列位请看！这东大是专揭旧疤，实在有碍体面！”

可这世界上的其他人也不是傻子。二十六国首脑欣然接受邀请，有人说得明白：“纪念反法西斯，是人类良知的义务！” 这话像一记耳光，抽在劝诫者的脸上，脆生生地响。

而东京的衮衮诸公，向来精于算计。删改几本教科书，供奉几束“真榊”祭品，再修宪扩军，图谋着将“自卫队”的招牌换成“国防军”，兴许就能将过往洗白。可我们中国人就是不肯忘，就是要年复一年地敲警钟。把钟声撞进太平洋，让大家瞧见“旧日本军魂”的招魂幡。于是他们恼羞成怒，要堵住天下人的耳，仿佛掩盖了钟声，历史便真成了任人涂抹的戏本。

可惜得很呐，墨写的谎，掩不住血写的事实。他们想要纪念广岛核爆中的呜咽，却要世人忘记南京城墙下的森森白骨。一边是德国总理跪在波兰纪念碑前的身影，一边是日本议员参拜靖国的香火绵绵。高下立判，何须多言！

鲁迅当年写“墨写的谎言，决掩不住血写的事实”，今日观之，竟似预言。

最可叹是那“反日”的帽子。我们念自己的殇，纪念自己的历史，又何曾指着富士山骂街？倒是这帮东瀛先生，将三百万冤魂的控诉当作“反日宣传”，将我们民族的伤口视作“外交威胁”。此番心思，就像被揪住辫子的泼皮，那横竖都是别人的错，自己是绝无半分的。

且看这出戏如何收场。他们的外交辞令、照会发得越勤，观礼的队列却越长。

待到纪念碑前的白菊连成一片海，浪涛里浮沉着1931至1945的数字。人群沉默着敬献花朵，无人言语，只听见风中的低语：“要记住，但别重复。”

至于那些缩在使馆里起草照会的先生们。

你们怕听礼炮？怕看红旗？怕那震耳欲聋的“胜利”二字？

那就怕着罢！

因为这是四万万人用血换来的，而血铸的真理，向来不惧墨写的谎.

阅读全文

状态迁移表

2025/08/08 工作 Linux

public enum OrderStatus {
    CREATED, // 订单创建
    UNPAID, // 订单待支付
    PAID, // 订单已支付
    TO_BE_SHIPPED, // 订单待发货
    SHIPPED, // 订单已发货
    CONFIRMED, // 订单确认
    COMPLETED, // 交易完成
    CANCELED // 订单已取消
}

public enum OrderEvent {
    PAY, // 支付
    SHIP, // 发货
    RECEIVE, // 确认收货
    CANCEL // 取消订单
}


public class OrderStateMachine {
    private static final Map<OrderStatus, Map<OrderEvent, OrderStatus>> stateMachine = new HashMap<>();
    static {
        // 定义状态转移表
        Map<OrderEvent, OrderStatus> createdTransitions = new EnumMap<>(OrderEvent.class);
        createdTransitions.put(OrderEvent.PAY, OrderStatus.UNPAID);
        createdTransitions.put(OrderEvent.CANCEL, OrderStatus.CANCELED);
        stateMachine.put(OrderStatus.CREATED, createdTransitions);

        Map<OrderEvent, OrderStatus> unpaidTransitions = new EnumMap<>(OrderEvent.class);
        unpaidTransitions.put(OrderEvent.PAY, OrderStatus.PAID);
        unpaidTransitions.put(OrderEvent.CANCEL, OrderStatus.CANCELED);
        stateMachine.put(OrderStatus.UNPAID, unpaidTransitions);

        Map<OrderEvent, OrderStatus> paidTransitions = new EnumMap<>(OrderEvent.class);
        paidTransitions.put(OrderEvent.SHIP, OrderStatus.TO_BE_SHIPPED);
        paidTransitions.put(OrderEvent.CANCEL, OrderStatus.CANCELED);
        stateMachine.put(OrderStatus.PAID, paidTransitions);

        Map<OrderEvent, OrderStatus> toBeShippedTransitions = new EnumMap<>(OrderEvent.class);
        toBeShippedTransitions.put(OrderEvent.RECEIVE, OrderStatus.CONFIRMED);
        toBeShippedTransitions.put(OrderEvent.CANCEL, OrderStatus.CANCELED);
        stateMachine.put(OrderStatus.TO_BE_SHIPPED, toBeShippedTransitions);

        Map<OrderEvent, OrderStatus> shippedTransitions = new EnumMap<>(OrderEvent.class);
        shippedTransitions.put(OrderEvent.RECEIVE, OrderStatus.CONFIRMED);
        shippedTransitions.put(OrderEvent.CANCEL, OrderStatus.CANCELED);
        stateMachine.put(OrderStatus.SHIPPED, shippedTransitions);

        Map<OrderEvent, OrderStatus> confirmedTransitions = new EnumMap<>(OrderEvent.class);
        confirmedTransitions.put(OrderEvent.CANCEL, OrderStatus.COMPLETED);
        stateMachine.put(OrderStatus.CONFIRMED, confirmedTransitions);
    }

    public static OrderStatus nextState(OrderStatus currentStatus, OrderEvent event) {
        Map<OrderEvent, OrderStatus> transitions = stateMachine.get(currentStatus);
        if (transitions == null) {
            throw new IllegalStateException("Invalid order status: " + currentStatus);
        }
        OrderStatus nextStatus = transitions.get(event);
        if (nextStatus == null) {
            throw new IllegalStateException("Invalid event " + event + " for order status " + currentStatus);
        }
        return nextStatus;
    }
}

假设我们有一个订单 order，它的状态为 ORDER_CREATED，接下来我们需要将它流转到 ORDER_PAID 状态，那么可以按照以下流程：

判断订单当前状态是否为 ORDER_CREATED 如果是，则将订单状态设置为 ORDER_TO_BE_PAID，并且更新订单的 update_time，同时添加一条状态变更记录到订单状态表中，记录的事件为 PAY_ORDER，表示用户支付订单进入支付流程，等待用户支付用户支付成功后，将订单状态设置为 ORDER_PAID，并且更新订单的 update_time，同时添加一条状态变更记录到订单状态表中，记录的事件为 ORDER_PAID，表示订单已支付

if (order.getOrderStatus() == OrderStatus.ORDER_CREATED) {
    order.setOrderStatus(OrderStatus.ORDER_TO_BE_PAID);
    order.setUpdateTime(new Date());
    orderStatusService.createOrderStatus(order.getOrderId(), OrderStatusEvent.PAY_ORDER, OrderStatus.ORDER_TO_BE_PAID);
    
    // 进入支付流程等待用户支付
    // ...
    
    order.setOrderStatus(OrderStatus.ORDER_PAID);
    order.setUpdateTime(new Date());
    orderStatusService.createOrderStatus(order.getOrderId(), OrderStatusEvent.ORDER_PAID, OrderStatus.ORDER_PAID);
}

原文

阅读全文

提高C++性能的编程技术

2024/05/21 技术 Performance Programming Techniques

提高C++性能的编程技术

导读

chapter 1

通过实现Trace跟踪，演示了如何提高性能

chapter 2

2.1 RAII实现，继承开销

2.2 说明了Trace类实现，String数据成员的复合开销

2.3 使用的地方再创建c++类对象

2.4 冗余构造，使用显示初始化

阅读全文

王德峰讲座问答

2022/01/30 生活 philosophy

问题：如何通过中国哲学找到自己人生的目的？

我们读中国哲学的典籍，了解儒道佛三家，因为儒道佛三家是中国哲学的主干，后来还合流，到宋明的时候儒道佛三家合流，仍然以儒家为根本。我们为什么要去读这些东西，一个最根本的原因就是中华民族不是一个宗教的民族，虽然这个民族有宗教徒的，但整个民族的文化精神不是宗教精神。我们不是在宗教信仰中安心立命，而人活在这个世界上必须要解决信仰的问题。

信仰是什么意思？可以给信仰下这样一个定义：信仰就是对生命价值的确认和对人生意义的领会。

那么其他民族都是用宗教来实现，用通过宗教来确认生命的价值，用基督教，用伊斯兰教或者什么教来确认领会人生的意义。比如说一个纯粹的穆斯林，他怎么领会人生的意义，他认为他自己的一生属于安拉属于真主的事业的一部分，他如此领会人生的意义。如果真主有伟大的事业要他去承担，他可以牺牲自己，那叫圣战。这是他们如此领会人生的意义，如此确认生命的价值。

那么我们中华民族向来靠什么安心立命，靠什么来确认我们生命价值和人生意义呢？

对生命价值的确认和对人生意义的领会，世界上各个民族并没有统一的东西，所以在这一点上我们离不开中国哲学。我们今天学中国的哲学，并不是扩大知识面的问题，并不是在我们缺乏人文知识的情况下再补充一点，不是这件事，也可以不扩大视野，也可以扩大视野？不。我们只有在儒道佛三家中我们才能找到安心立命的地方，而儒道佛三家哲学的思想的合流，就是在宋朝和明朝，他的最高成果就是陆象山王阳明的心学，心学是中华民族安心立命的学问。

我们不可能在西方哲学中或者西方的科学中安心立命，这个问题他们不可能回答。而且西方也不是在哲学中安心立命，在基督教。

我想大概回答了这个问题。

阅读全文

专用架构与AI软件栈

2021/12/11 技术 DSA

本文来自知乎mackler，作者是清华计算机博士，其中是他对于DSA和AI软件栈问题的思考，文章很有洞察力，写得非常棒。

开个新系列，聊一聊专用架构和AI软件栈的问题。这个题目比较大，涉及面非常广，和之前的文章一样，我一般观点都比较激进，对于现有方法的缺点一般是毫不掩饰，各位看官请酌情食用，另外我也会抛出一些全新的解决思路。

这篇文章主要先聊硬件，AI软件栈的复杂性和根本性难题其实主要来源于硬件。如果硬件只是GPU，尤其是是Volta架构之前的GPU，其实AI软件栈根本不用这么复杂，所以我们先来讲讲硬件架构，也是我的老本行。

体系结构领域大的创新其实已经停滞了很多年了，虽然说这么多年硬件的提升一半是靠摩尔定律，一半是靠体系结构革新，作为一个做arch的，我原先也非常相信arch在其中的作用。但实际情况是，arch的“创新”其实很大程度依赖于工艺的演进。arch领域最近几年最常见的论调是摩尔定律要完蛋了，arch即将成为硬件性能的主要推动力，似乎未来架构要在工艺不变的情况下纯靠架构演进原地起飞。实际并不是，脱离了工艺的演进，架构带来收益非常困难！

架构的收益其实更多是工艺演进时，新约束下新tradeoff带来的超额收益。以前我也不明白这一点，因为理论上讲，架构只是电路逻辑，什么工艺下都可以做。但实际上工艺可以打开设计的空间，因为相同的面积功耗限制下，新工艺可以放更多的逻辑，我们就可以把原有架构的各个部分超级加倍，比如cache变大，发射数增大。但随之而来原先架构不突出的问题可能就变得明显，此时就需要调整架构，比如cache太大了就可以再加一级，利用率可以更高，从而获得超额的提升（相比简单根据工艺scale）。所以本质上讲，不同工艺带来的不同约束下，架构设计是有不同tradeoff选择的，所谓架构收益更多是这种新tradeoff带来的超额提升。但如果约束保持不变，其实最佳的tradeoff很快就收敛了，后面想继续靠arch压榨出更多性能就非常困难了。

阅读全文