docker容器中的Jdk-availableProcessors

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

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获取可用核数错误，拿到的是宿主机核数而非容器可用核数¹。

Apache Calcite: A Foundational Framework for Optimized Query Processing Over Heterogeneous Data Sources

本篇是论文的中文简单翻译

摘要

Apache Calcite 是一个基础软件框架，可提供查询处理，优化和查询语言支持，目前已支持多种流行的开源数据处理系统，例如Apache Hive，Apache Storm，Apache Flink，Druid和MapD。Calcite 的体系结构包括具有数百种内置优化规则的模块化可扩展查询优化器，能够处理多种查询语言的查询处理器，为可扩展性设计的适配器体系结构以及对异构数据模型和存储（关系，半 结构化，流式传输和地理空间）。这种灵活，可嵌入和可扩展的架构使 Calcite 在大数据框架中采用更具有吸引力。这是一个活跃的项目，正持续引入对新型数据源，查询语言以及查询处理和优化方法的支持。

Java项目打包时HeapSpace OOM

maven 打包时HeapSpace OOM

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

在系统的环境变量中，设置MAVEN_OPTS，用以存放JVM的参数:

1

export MAVEN_OPTS=-Xms256m -Xmx768m -XX:PermSize=128m -XX:MaxPermSize=256M

除了Maven主进程之外，单测插件surefire起的进程也可能出现OOM异常。surefire插件可以拉出几个JVM进程，以及每个进程的JVM配置是如何的，都是可以配置的(见官方文档)。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<!--注意argLine配置可以用于传递JVM参数-->
<plugins>
[...]
  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>3.0.0-M5</version>
    <configuration>
        <forkCount>3</forkCount>
        <reuseForks>true</reuseForks>
        <argLine>-Xmx1024m -XX:MaxPermSize=256m</argLine>
        <systemPropertyVariables>
            <databaseSchema>MY_TEST_SCHEMA_${surefire.forkNumber}</databaseSchema>
        </systemPropertyVariables>
        <workingDirectory>FORK_DIRECTORY_${surefire.forkNumber}</workingDirectory>
    </configuration>
  </plugin>
[...]
</plugins>

gradle 打包时HeapSpace OOM

在gradle工程的gradle.properties里配置org.gradle.jvmargs=-Xmx2000m -Xms500M -XX:+HeapDumpOnOutOfMemoryError

test命令不能触发Junit5测试用例

maven不能触发Junit5测试用例

使用 MAVEN PACKAGE打包时，JUnit4可以在打包时运行全部测试用例，而JUnit5不会运行。这是因为现在 maven 并不能直接识别JUnit5测试用例，需要在插件中添加 maven surefire。

1
2
3
4
5
6
7
8
9

<build>
   <plugins>
     <!--fix: mvn test not run junit5 @Test -->
     <plugin>
       <artifactId>maven-surefire-plugin</artifactId>
       <version>2.22.2</version>
     </plugin>
   </plugins>
 </build>

再次运行 mvn clean pacakge 即可触发TestCase。

gradle不能触发Junit5测试用例

在项目下使用./graldew test,不能触发Junit5的测试用例，但是Junit4是可以的。

1
2
3
4
5

buildscript {
  dependencies {
      classpath ("org.junit.platform:junit-platform-gradle-plugin:1.0.0-M4")
  }
}

编译原理-词法分析

编译器模型：

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

MurmurHash

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

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

响应式宣言

版本 2.0，2014 年 9 月 16 日发布

在不同领域中深耕的组织都在不约而同地尝试发现相似的软件构建模式。 希望这些系统会更健壮、更具回弹性 、更灵活，也能更好地满足现代化的需求。

近年来，应用程序的需求已经发生了戏剧性的更改，模式变化也随之而来。仅在几年前， 一个大型应用程序通常拥有数十台服务器、 秒级的响应时间、 数小时的维护时间以及GB级的数据。 而今，应用程序被部署到了形态各异的载体上, 从移动设备到运行着数以千计的多核心处理器的云端集群。 用户期望着毫秒级的响应时间，以及服务100%正常运行（随时可用）。 而数据则以PB计量。 昨日的软件架构已经根本无法满足今天的需求。

我们相信大家需要一套贯通整个系统的架构设计方案， 而设计中必需要关注的各个角度也已被理清， 我们需要系统具备以下特质：即时响应性（Responsive）、回弹性（Resilient）、弹性（Elastic）以及消息驱动（Message Driven）。 我们称这样的系统为反应式系统（Reactive System）。

RAID技术

RAID （ Redundant Array of Independent Disks ）即独立磁盘冗余阵列，通常简称为磁盘阵列。简单地说， RAID 是由多个独立的高性能磁盘驱动器组成的磁盘子系统，从而提供比单个磁盘更高的存储性能和数据冗余的技术。

Apache Flink™: Stream and Batch Processing in a Single Engine

本篇是论文的中文简单翻译

Apache Flink 是一个开放源代码系统，用于处理流数据和批处理数据。Flink的哲学是，许多类别的数据处理应用程序（包括实时分析，数据管道，历史数据处理（批处理）和迭代算法（机器学习，图形分析）都可以表示为容错的流水线数据流并执行。在本文中，我们提出Flink的体系结构，并就如何在单一执行模型下执行一组多样性用例进行扩展分析。

分布式锁简介

在分布式场景中分布式锁是一种很常见的需求。实现一个分布式锁要注意以下几点:

• 安全: 独享（相互排斥）。在任意一个时刻，只有一个客户端持有锁。
• 锁失效保护: 无死锁。即便持有锁的客户端崩溃（crashed)或者网络被分裂（gets partitioned)，锁仍然可以被获取。
• 集群容错。 只要大部分Redis节点都活着，客户端就可以获取和释放锁。
• 原子性：获取释放锁最好是原子操作，获取释放锁的性能要好。
• 可重入(optional): 同一个线程在没有释放锁之前，如果想再次操作，可以直接获得锁。
• 阻塞/非阻塞(optional)：若没有获取到锁，返回获取失败。