循环冗余校验（英语：Cyclic redundancy check，通称“CRC”）是一种根据网络数据包或电脑文件等数据产生简短固定位数校验码的一种散列函数，主要用来检测或校验数据传输或者保存后可能出现的错误。生成的数字在传输或者存储之前计算出来并且附加到数据后面，然后接收方进行检验确定数据是否发生变化¹。

最近遇到一个问题，在执行长事务任务的过程中，频繁出现异常 com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: Communications link failure during commit(). Transaction resolution unknown.即，事务提交时发现连接已经失效。一开始以为是连接超时设置的有问题，但是这个异常重复出现，并且，数据库连接池设置了testOnBorrow。所以应该不是连接超时导致。后来发现，出现报错时，事务开启都刚好超过了5S。

经过和RDS同学的沟通。他们设置了kill_idle_transaction 这个参数，并且默认为5S

在线上遇到5.7.26的锁问题，需要解决idle事务长时间挂起的问题。同时也调研了现有的mysql timeout机制，以确保其和现有的timeout机制可以吻合。Percona从5.1.59-13.0引入了innodb_kill_idle_transaction，用于解决长事务场景，即对idle事务设定一个超时时间，对超过该时间的事务所在的用户连接进行断开。

最近在线上环境遇到一个问题，nacos客户端线程池中有96个线程在等待.一开始以为是哪里配置有误，于是检查了nacos的配置。没有发现问题。于是只能看nacos源码了.

public ClientWorker(final HttpAgent agent, final ConfigFilterChainManager configFilterChainManager, final Properties properties) {
        this.agent = agent;
        this.configFilterChainManager = configFilterChainManager;

        // Initialize the timeout parameter

        init(properties);

        executor = Executors.newScheduledThreadPool(1, new ThreadFactory() {
            @Override
            public Thread newThread(Runnable r) {
                Thread t = new Thread(r);
                t.setName("com.alibaba.nacos.client.Worker." + agent.getName());
                t.setDaemon(true);
                return t;
            }
        });

        executorService = Executors.newScheduledThreadPool(Runtime.getRuntime().availableProcessors(), new ThreadFactory() {
            @Override
            public Thread newThread(Runnable r) {
                Thread t = new Thread(r);
                t.setName("com.alibaba.nacos.client.Worker.longPolling." + agent.getName());
                t.setDaemon(true);
                return t;
            }
        });

        executor.scheduleWithFixedDelay(new Runnable() {
            @Override
            public void run() {
                try {
                    checkConfigInfo();
                } catch (Throwable e) {
                    LOGGER.error("[" + agent.getName() + "] [sub-check] rotate check error", e);
                }
            }
        }, 1L, 10L, TimeUnit.MILLISECONDS);
    }

如上面的代码，nacos长轮询线程池在初始化时使用了Runtime.getRuntime().availableProcessors().而宿主机恰好是48核*2。因此判断JVM获取可用核数错误，拿到的是宿主机核数而非容器可用核数¹。

在前面的编译原理-词法分析一文中，我们介绍了基于正则表达式方式构建NFA和DFA进行词法分析的方案。本文将基于该方案，扩展一些功能，实现一个正则表达式执行引擎JRegex - alpha版本。

本篇是论文Apache Calcite: A Foundational Framework for Optimized Query Processing Over Heterogeneous Data Sources的中文简单翻译

解析是编译器将一系列标记转换为树表示的过程：

                            Add
                 Parser     / \
"1 + 2 * 3"    ------->   1  Mul
                              / \
                             2   3

Pratt Parser解析是手写解析最常用的技术之一。

maven 打包时HeapSpace OOM

maven打包时出现HeapSpace OOM问题。由于Maven是Java启动的，显然我们只要修改maven进程的JVM配置就可以了。

最近在maven打包的时候遇到一个问题:

编译器模型：

graph LR
源代码-->|词法分析器|词法单元
词法单元-->|语法分析器|语法分析树
语法分析树-->|中间代码生成器|中间代码
中间代码-->|代码优化,机器无关|中间代码
中间代码-->|代码生成器|目标代码
目标代码-->|机器相关代码优化|机器码
机器码-->output((机器码执行))

MurmurHash 是一种非加密hash功能，适用于基于hash的一般查找。由Austin Appleby在2008年发明， 并出现了多个变种，目前托管在github。该名称来自两个基本操作，乘 multiply 和 旋转 rotate(该算法实际上使用shift和xor而不是rotate)，用于其内循环。与其它流行的哈希函数相比，对于规律性较强的key，MurmurHash的随机分布特征表现更良好。

Redis在实现字典时用到了两种不同的哈希算法，MurmurHash便是其中一种（另一种是djb），在Redis中应用十分广泛，包括数据库、集群、哈希键、阻塞操作等功能都用到了这个算法。该算法最新版本是MurmurHash3，基于MurmurHash2改进了一些小瑕疵，使得速度更快，实现了32位（低延时）、128位HashKey，尤其对大块的数据，具有较高的平衡性与低碰撞率。