z217's blog

C++协程（5）：理解编译器转换

Wed, 23 Apr 2025 23:34:19 +0800

介绍

之前的“理解C++协程”文章中讲到了编译器会对协程，以及它的 $co_-await$、$co_-yield$、$co_-return$ 表达式执行的不同类型的转换。这些文档描述了编译器如何将每个表达式翻译成底层的对多种自定义的点 / 用户定义的方法调用。

        然而，这些描述还有一部分你可能不太满意。它们对于“挂起点”的概念一笔带过，含糊地说成“协程在这里挂起”、“协程在这里恢复”，并没有详细说明它的含义，以及编译器是怎么实现的。
        在这篇文章，我会把之前文章的所有概念更深入地讲解。我会把一个协程转换为底层等价的非协程、命令式的C++代码，来展示当协程执行到挂起点时发生了什么。
        注意我不会描述某个特定编译器怎么把协程编译成机器码 ( 编译器在这方面会有些额外技巧 )，而是只描述一种可能的把协程转化成可移植的C++代码的方式。
        警告：这次讨论会有点深！

设置场景

对于初学者，我们假设有一个基本的 $task$ 类型，同时作为 $awaitable$ 和协程的返回类型。为了简化，假设这个协程类型异步生成一个 $int$ 类型结果。
在这篇文章，我们会描述怎么把下面的协程代码转换为不包含任何协程关键字 $co_-await$、$co_-return$的C++代码，以便我们更好理解它的含义。

// Forward declaration of some other function. Its implementation is not relevant.
task f(int x);

// A simple coroutine that we are going to translate to non-C++ code
task g(int x) {
  int fx = co_await f(x);
  co_return fx * fx;
}

定义 task 类型

        首先，我们声明一个会被用到的 $task$ 类。
        为了理解协程怎么转化成底层代码，我们不需要明白这个类型的方法定义。对它们的调用会被插入转换中。
        这些方法的定义并不复杂，我会把它们作为读者理解以前文章的练习实践。

class task {
public:
  struct awaiter;

  class promise_type {
  public:
    promise_type() noexcept;
    ~promise_type();

    struct final_awaiter {
      bool await_ready() noexcept;
      std::coroutine_handle<> await_suspend(
        std::coroutine_handle<promise_type> h) noexcept;
      void await_resume() noexcept;
    };

    task get_return_object() noexcept;
    std::suspend_always initial_suspend() noexcept;
    final_awaiter final_suspend() noexcept;
    void unhandled_exception() noexcept;
    void return_value(int result) noexcept;
  
  private:
    friend task::awaiter;
    std::coroutine_handle<> continuation_;
    std::variant<std::monostate, int, std::exception_ptr> result_;
  };

  task(task&& t) noexcept;
  ~task();
  task& operator=(task&& t) noexcept;

  struct awaiter {
    explicit awaiter(std::coroutine_handle<promise_type> h) noexcept;
    bool awaite_ready() noexcept;
    std::coroutine_handle<promise_type> await_suspend(
      std::coroutine_handle<> h) noexcept;
    int await_resume();
  private:
    std::coroutine_handle<promise_type> coro_;
  };

  awaiter operator co_await() && noexcept;

private:
  explicit task(std::coroutine_handle<promise_type> h) noexcept;

  std::coroutine_handle<promise_type> coro_;
};

这个 $task$ 类型的定义与理解 $promise$的相似。

C++协程（4）：理解对称转移

Sun, 28 Jan 2024 23:45:37 +0800

        协程标准提供了一种有趣的方式来编写异步代码，就好像你还在写同步代码那样。你只需要在合适的点调用 $co_-await$，编译器就会负责挂起协程，在挂起点之间保存状态，并在操作完成后恢复协程执行。
        然而，协程标准，就像它最初定义的那样，有着很不友好的限制，一不小心就很容易导致栈溢出。并且如果想要避免这种溢出，就需要你在的 $task$<$T$> 类型中进行额外的同步开销。
        还好，2018年对协程设计进行了调整，增加了一种叫做“对称转移” ( $symmetric$ $transfer$ ) 的功能，让你可以在不消耗任何额外栈空间的前提下挂起一个协程的同时恢复另一个协程的执行。此功能的加入解决了协程标准的一个关键限制，并且允许更简单有效的，不需要任何安全方面的措施来防止栈溢出的方式来实现一个异步协程。
        在这篇文章我会试着解释栈溢出问题，以及这个关键的“对称转移”能力是怎么解决这个问题的。

首先是一些关于任务协程怎么工作的背景

考虑如下协程：

task foo() {
  co_return;
}

task bar() {
  co_await foo();
}

假设我们有一个简单的 $task$ 类型，当其他协程等待它时会懒执行。这个特别的 $task$ 类型没有返回值。
让我们分析下当 $bar\left(\right)$ 执行 $co_-await$ $foo\left(\right)$ 时发生了什么。

$bar\left(\right)$ 协程调用 $foo\left(\right)$ 函数。注意从调用方的角度看协程只是一个普通函数。
$foo\left(\right)$ 调用执行一些步骤：
- 分配协程帧内存 ( 一般在堆上 )。
- 把参数拷贝到协程帧 ( 如果没有参数，不执行这一步 )。
- 在协程帧构造 $promise$ 对象。
- 调用 $promise.get_-return_-object\left(\right)$ 来获取 $foo\left(\right)$ 的返回值。这一步生成将被返回的 $task$ 对象，使用指向刚创建的协程帧的 $std$::$coroutine_-handle$ 初始化。
- 在最初挂起点 ( 即左大括号 ) 处挂起协程。
- 把 $task$ 对象返回给 $bar\left(\right)$。
接着 $bar\left(\right)$ 协程对 $foo\left(\right)$ 返回的 $task$ 执行 $co_-await$ 表达式。
- $bar\left(\right)$ 协程挂起，调用返回的 $task$ 对象的 $await_-suspend\left(\right)$ 方法，传入指向 $bar\left(\right)$ 协程帧的 $std$::$coroutine_-handle$ 。
- $await_-suspend\left(\right)$ 函数保存 $bar\left(\right)$ 的 $std$::$coroutine_-handle$ 到 $foo\left(\right)$ 的 $promise$ 对象中，调用 $foo\left(\right)$ 的 $std$::$coroutine_-handle$ 的 $.resume\left(\right)$ 方法，恢复 $foo\left(\right)$ 协程的执行。
$foo\left(\right)$ 协程同步执行完成。
$foo\left(\right)$ 协程在最终挂起点 ( 即右大括号 ) 处挂起，通过开始执行前存储的 $promise$ 对象的 $std$::$coroutine_-handle$ ( 即 $bar\left(\right)$ 协程 ) 恢复 $bar\left(\right)$ 的执行。
$bar\left(\right)$ 协程恢复，继续执行，直到到达 $co_-await$ 表达式语句的结尾，这时它调用 $foo\left(\right)$ 返回的临时变量 $task$ 的析构函数。
$task$ 的析构函数再调用 $foo\left(\right)$ 协程句柄的 $.destroy\left(\right)$ 方法，销毁协程帧，包括 $promise$ 对象和拷贝的参数。

好，这么看来一个简单的调用包含了许多步骤。
为了更好地理解这些步骤，让我们看看一种简单的使用协程标准设计 ( 不支持对称转移 ) 的 $task$ 类实现。

C++协程（3）：理解promise

Sat, 27 Jan 2024 16:19:06 +0800

这篇文章是C++协程标准系列的第三篇文章。
之前的文章可以在这里查看：

在这篇文章我会讲解你写的代码是怎么被编译器编译成协程代码的，并且你可以通过定义自己的 $Promise$ 类型来自定义协程行为。

协程概念

        协程标准添加了三个新的关键字：$co_-await$，$co_-yield$ 和 $co_-return$ 。无论你在函数体里使用哪个，编译器都会把这个函数编译成协程，这个函数也不再是普通函数。
        编译器使用一些相当机械的转换来把你写的代码变成状态机，从而可以在函数内的特定点挂起，并在之后恢复执行。
        在之前的文章我描述了协程标准引入的两个接口中的第一个接口：$Awaitable$ 接口。而第二个接口, $Promise$ 接口则对于这种代码转换来说十分重要。
        $Promise$ 接口规定了自定义它所在协程行为的方法。库开发者可以用它定义协程被调用时的行为，协程返回的行为 ( 包括普通方式返回或者通过未处理异常返回 )，协程内使用 $co_-await$ 或者 $co_-yield$ 表达式的行为。

Promise对象

$Promise$ 对象通过实现协程执行过程中特定点的调用方法的形式来定义和控制对应协程的行为。

在继续之前，我希望你能忘掉之前所有关于 $promise$ 是什么的记忆。在一些用例中，协程的 $promise$ 对象与 $std$::$future$ 的 $std$::$promise$ 的功能很相似，但在其他用例中，并不能拿来相比。可能把协程的 $promise$ 对象想象成一个用于控制协程行为、跟踪协程状态的“协程状态控制器”会更合适。

        $promise$ 对象实例会跟随着每个协程函数调用时创建的协程帧一起被构造。
        编程器会在协程执行的关键点生成对 $promise$ 对象的特定方法的调用。
        在接下来的例子中，我们把某个特定协程在协程帧内创建的 $promise$ 对象叫做 $promise$ 。
        当你编写一个协程函数体 <$body$-$statement$> ，函数体包含了某个协程关键字 ( $co_-return$，$co_-await$，$co_-yield$ )，那么协程体将转变为 ( 大致地 ) 如下形式：

{
  co_await promise.initial_suspend();
  try
  {
    <body-statement>
  }
  catch (...)
  {
    promise.unhandled_exception();
  }
FinalSuspend:
  co_await promise.final_suspend();
}

一个协程函数被调用后，在执行之前会有一系列的准备步骤，这些步骤与常规的函数会有些不同。
以下是一个步骤总结 ( 我会在接下来详细介绍每个步骤 )：

C++协程（2）：理解co_await

Thu, 25 Jan 2024 00:00:42 +0800

        在之前的文章中，我介绍了函数和协程在高级表现的区别，但还没有讲到到C++协程标准的语法和语义。
        C++协程标准提供的一个关键能力是挂起协程，并在之后恢复。这个机制是通过 $co_-await$ 提供的。
        在揭开协程的神秘面纱前，我们需要理解 $co_-await$ 的工作方式，了解它是如何挂起和恢复协程的。在这篇文章中，我会解释 $co_-await$ 的机制，并介绍Awaitable与Awaiter的概念。
        在这之前，作为背景，我想先简单回顾下协程标准。

协程标准带来了什么？

三个关键字 $co_-await$ ，$co_-yield$ 和 $co_-return$
一些 $std$::$experimental$ 命名空间的新类型：
- $coroutine_-handle$<$P$>
- $coroutine_-traits$<$Ts$…>
- $suspend_-always$
- $suspend_-never$
一种允许库开发者与协程交互、定制化行为的机制
一个让异步代码更容易编写的语言能力

C++协程标准可以认为在语言层面提供了一个低级汇编语言协程。这些功能很难以一种安全的方式直接使用，主要是提供给库开发者来实现高级抽象，从而应用开发者可以安全使用。
之后的语言标准 ( 希望是C++20 ) 计划加入这些低级功能，同时让标准库提供一些包装了这些功能的高级类型，让应用开发者以更方便安全的方式使用。

编译器 <-> 库交互

        有趣的是，协程标准并没有明确定义协程语义，包括协程如何把值返回给调用方，$co_-return$ 如何处理返回值，如何处理传播到协程之外的异常，以及协程应该在哪个线程恢复。
        相反的，它指定了一种可以让库代码定制化协程行为的机制，通过实现特定的接口类型。编译器使用库代码生成对应的调用。这种方式很像range模式，后者可以让库开发者通过定义 $begin\left(\right)$ / $end\left(\right)$ 和 $iterator$ 类型，来定制化代码。
        协程的这种没有给机制定义特殊语义的方式，让它变成了一个强大的工具，允许库开发者实现各种类型的协程，以各种方式，出于各种目的。
        例如，你可以实现一个异步生成单个值的协程，或者一个懒生成值序列的协程，或者一个简单消费 $optional$<$T$> 值，如果遇到 $nullopt$ 就提前退出的协程。
        协程标准定义了两个接口：$Promise$ 和 $Awaitable$ 。
        $Promise$ 接口指定了协程定制化行为的方法。库开发者可以通过该接口，实现当协程被调用时的行为，协程返回时的行为 ( 包括正常返回和抛出未处理异常 )，协程内使用 $co_-await$ 或者 $co_-yield$ 的行为。
        $Awaitable$ 接口指定控制 $co_-await$ 语义的方法。当一个值是可以 $co_-await$ 的，代码就会被翻译成一系列的对 $awaitable$ 对象方法的调用。这个对象可以决定是否挂起当前协程，在挂起前执行一些逻辑用于后续的恢复，以及在恢复后生成 $co_-await$ 表达式的值。
        我会在之后的文章再介绍 $Promise$ ，现在先来看看 $Awaitable$ 接口。

C++协程（1）：协程理论

Tue, 23 Jan 2024 23:59:20 +0800

        这是C++ Coroutines标准 ( C++ Coroutines TS ) 系列的第一篇文章，协程作为新技术被引入C++20标准。
        在这个系列里我会介绍C++协程的底层机制，以及如何使用它们实现一些更高级的抽象，就像 cppcoro 库一样。
        在这篇文章，我会介绍函数和协程的区别，以及相应的一些他们所支持的行为的理论。文章的目标是介绍一些基础概念，帮助你理解C++协程。

协程是函数，函数是协程

协程是一种允许挂起 ( $suspend$ ) 和恢复 ( $resume$ ) 的函数的统称。
在解释这个含义之前，我们先复习一下一个“普通”C++函数的行为是什么。

“普通”函数

        一个普通函数具有两种行为：调用 ( $call$ ) 和返回 ( $return$ , 注意这里返回也包括了抛出异常 )。
        调用创建一个调用帧 ( $activation$ $frame$ )，挂起调用方函数，执行被调函数的第一条命令。
        返回会把返回值返回给调用方，销毁调用帧，然后在调用方函数的调用点处，恢复调用方函数执行。
        让我们再分析一下这些语义……

调用帧

        什么是“调用帧”？
        你可以认为调用帧是一块存储着特定函数调用状态的内存块，这些状态包括了入参和局部变量。
        对于“普通”函数，调用帧也包含返回地址——函数返回时将跳转到的指令，和调用方函数的调用帧地址。这两部分组成了函数调用的后续执行上下文 ( $continuation$ ) ，即当前函数调用完后，下一步应该继续执行哪个函数调用，从哪开始执行。         对于“普通”函数，所有的调用帧都有着严格嵌套的生命周期。严格嵌套可以更有效地分配和释放每个函数调用的调用帧，这种数据结构也被称为“栈”。
        调用帧分配在栈上，也被称为“栈帧”。
        栈是一种十分常见的数据结构，大部分CPU架构都有个专门的寄存器来保存栈顶地址 ( 例如，X64的rsp寄存器 )。
        分配一个调用帧，只需要让寄存器加上栈帧大小的值。同样的，释放一个调用栈，只需要让寄存器减去栈帧大小。

调用

        当一个函数调用另一个函数，调用方必须准备进入“挂起”状态。
        “挂起”阶段通常涉及保存当前CPU寄存器中的值，并在之后恢复的时候重新设置这些值。保存寄存器这一步，可以是调用方执行，也可以是被调方执行，取决于不同的调用方式，但你可以认为它们都是调用的一部分。
        调用也会把入参在新的调用栈里保存一份，让被调可以访问。
        最后，调用方在新调用栈里面写入恢复点的地址，并把执行权让出给被调函数。
        在X86/X64架构，最后一步有单独对应的 $call$ 指令，会把当前指令的下一条指令地址写入栈，递增栈寄存器，然后跳转到指令操作地址。

当一个函数通过 $return$ 返回，函数会先把返回值保存到调用方可以访问的地方，可以是调用方调用帧，也可以是当前调用帧 ( 对于跨越两个调用帧的参数和返回值，这种概念可能没有明确的区别 )。
然后函数通过以下步骤销毁调用帧：

分布式数据系统：共识算法

Sun, 13 Nov 2022 16:18:06 +0800

分布式计算中有很多重要场景需要集群节点达成某种一致，例如：

主节点选举：对于主从模式的数据库，节点间需要对谁来充当主节点达成一致。如果由于网络故障原因出现节点之间无法通信，就很容易出现争议；
原子事务提交：对于支持跨节点或跨分区事务的数据库，某个事务可能在一些节点上执行成功，而在另一些节点上失败。为了维护事务的原子性，所有节点必须对事务结果达成一致。

1. 原子提交与两阶段提交

        对于单节点事务，原子性通常由存储引擎负责。当客户端请求数据库节点提交事务时，数据库首先使事务的写入持久化 ( 通常保存在WAL中 )，然后把提交记录追加到磁盘的日志文件中。如果数据库在该过程中发生了崩溃，在节点重启后，可以通过日志恢复事务。如果崩溃之前已经写入了提交记录，则认为事务已经成功，否则，回滚该事务。因此，单节点事务十分依赖于数据写入磁盘的顺序：先写入数据，再提交记录。
        将单节点事务延伸到多节点，虽然大多数NoSQL分布式数据库都不支持这种分布式事务，但是有很多集群关系型数据库支持。向所有节点发送请求，然后各节点独立执行是不够的，这样很容易发生不一致，从而违反了原子性。一旦某个节点提交了事务，即使事后发现其他节点发生了中止，它也无法再撤销已提交的事务，所以，如果有部分节点提交了事务，所有节点也必须一起提交。
        事务提交不可撤销，一旦数据被提交，就代表其他事务可见，继而客户端会依赖这些数据做出相应决策。这是事务提交读隔离级别的基础，如果事务在提交后还能撤销，就违反了提交读的原则，从而被迫产生级联式的追溯和撤销。当然，已提交事务可以被另一个新的事务覆盖，即补偿性事务。不过，在数据库的角度，它们是两个完全独立的事务，这种跨事务的正确性保证需要应用层负责。

1.1 两阶段提交

两阶段提交 ( $two-phase\ commit$ , $2PC$ ) 是一种在多节点之间实现事务原子提交的算法，用来确保所有节点要么全部提交，要么全部中止。2PC在某些数据库内存使用，或者以XA事务的形式提供给应用程序使用。
2PC引入了单节点事务所没有的新组件：协调者 ( 也被称为事务管理器 )，通常实现为共享库。2PC事务从应用程序在多个数据库节点上执行数据读/写开始，数据库节点称为事务的参与者。当应用程序准备提交事务时，协调者发送一个准备请求到所有节点，询问它们是否可以进行事务提交：

如果所有参与者回答是，表示它们已经准备好提交，协调者会发出提交请求，所有节点开始执行事务提交；
如果有任何参与者回答否，协调者会放弃发送提交请求。

为了理解2PC，我们可以分解这个过程：

应用程序启动一个分布式事务，首先向协调者请求一个全局唯一的事务ID；
应用程序在每个参与节点上执行单节点事务，并将全局唯一事务ID附加到事务上。此时，每个节点独立执行事务，如果有任何一个节点执行失败，协调者和其他参与者都可以安全回滚事务；
应用程序准备提交事务，协调者向所有参与者发送准备请求，附带全局事务ID。如果接收到拒绝或者超时响应，协调者会通知所有节点放弃事务；
参与者在收到准备请求后，检查事务是否可以提交，是否存在冲突或者违反约束。一旦向协调者返回确认响应，无论发生什么情况，都不能拒绝提交事务；
协调者收到所有准备请求的响应后，会将决定写入磁盘中，用于崩溃后恢复决定，这个时刻称为提交点；
协调者将决定写入磁盘后，向所有参与者发送提交或者放弃请求。如果请求出现失败或者超时，协调者会一种重试，直到成功。所有参与者都不能拒绝该请求，即使需要很多重试，或者中间出现崩溃。

如果参与者或者网络在2PC期间发生故障，比如在准备请求期间，协调者就会决定回滚事务；或者在提交请求期间，协调者会不断重试。而对于协调者故障，如果协调者在准备请求之前故障，参与者可以安全地回滚；而一旦参与者收到了准备请求并回答是，参与者便无法单方面放弃，必须一直等待协调者的决定，此时如果协调者故障，参与者便处于一种不确定的状态。理论上，参与者之间可以互相通信，了解每个参与者的投票情况，并达成一致，但是这已经不是2PC的范畴了。2PC能够顺利完成的唯一办法是等待协调者恢复，因此协调者在发送提交请求之前要将决定写入磁盘的事务日志。
2PC也被称为阻塞式原子提交协议，因为等待协调者从故障恢复的这个过程是阻塞的。理论上，也可以改为非阻塞的，这种称为三阶段提交。3PC假定一个有限的网络延迟，要求节点在规定时间内响应。然而实际情况是，网络延迟可能是无限的。通常，非阻塞原子提交依赖一个完美的故障检测器，即一种十分可靠的可以判断节点是否崩溃的机制。但是，在一个网络延迟可能是无限的场景中，超时并非一种可靠的判断机制。正常情况下，请求也可能由于网络问题而超时。正是这些原因，大家更倾向于2PC而非3PC。

2. 分布式事务实践

分布式事务，尤其是那些通过2PC实现的事务，声誉混杂。一方面，它们提供了一种其他方案难以企及的安全保证。但是另一方面，由于操作、性能上的缺陷，以及并非完全可靠，一直被人诟病。目前，许多云服务商由于运维方面的问题而决定不支持分布式事务。分布式事务的某些实现存在严重的性能问题，例如，有报告显示MySQL的分布式事务比单节点事务慢 $10$ 倍以上。2PC性能下降的主要原因是与协调者通信带来额外的网络开销，以及为了协调者崩溃恢复做的磁盘I/O ( $fsync$ )。
目前存在着两种不同的分布式事务概念：

数据库内部的分布式事务：某些分布式事务支持的跨数据节点的内部事务，即所有参与者节点运行着相同的数据库软件；
异构分布式事务：存在两种或两种以上不同参与者软件的事务，例如来自不同供应商的数据库，甚至可以是非数据库。

对于数据库内部事务，由于不需要考虑不同系统之间的兼容，可以采用任何形式的协议，并进行针对性优化，这些分布式事务往往可行。但是异构分布式事务就没那么简单了。

2.1 `Exactly-once`消息处理

异构分布式事务旨在无缝集成多种不同的系统。例如，当且仅当数据库中处理消息的事务成功提交，消息队列才会标记该消息已处理完毕。这个过程是通过自动提交消息确认和数据库写入实现的。即使消息系统和数据库运行在不同节点上，分布式事务也能实现上述目标。如果消息发送失败或者某个节点事务失败，两者都必须中止。消息队列可以在之后重传消息。因此通过自动提交和消息处理结果，可以确保消息有效处理只有一次。
需要注意，只有所有相关系统都使用相同的原子性提交协议的前提下，这种分布式事务才是可行的。例如，如果处理结果之一是发送邮件，而邮件服务器不支持2PC，此时某个过程出错，消息重新入队重试，邮件就可能会被发送多次。

2.2 `XA`事务

        X/Open XA ( $eXtended\ Architecture$ , $XA$ ) 是异构环境下进行2PC的一个工业标准。目前，许多关系型数据库 ( PostgreSQL、MySQL、Oracle等 ) 和消息队列 ( ActiveMQ、MSMQ、IBM MQ等 ) 都支持XA。XA并不是一个网络协议，而是一个与事务协调者进行通信的C API。当然，它也支持与其他语言的API绑定，例如Java。
        XA假定应用程序通过网络或客户端的库函数与参与者节点进行通信，如果驱动程序支持XA，意味着应用程序可以调用XA API确定操作是否属于异构分布式事务的一部分。如果是，则发送必要的信息给数据库服务器。它还支持回调，这样协调者可以通过回调函数通知所有参与者执行准备或者提交 ( 或者中止 )。
        协调者需要实现XA API。虽然标准没有规定如何实现，但实际上，协调者也通常是一个API库，与产生事务的应用程序运行在相同进程中。这些API跟踪事务的参与者，收集投票，并在本地磁盘中记录决定。如果应用程序发生崩溃，或者节点故障，在重启后，协调者会通过XA API读取日志，恢复决定。完成这些后，协调者才能继续通过回调函数来要求参与者执行提交或者中止。数据库服务器无法直接与协调者通信，必须通过相应API。

分布式数据系统：主从节点

Sun, 06 Nov 2022 15:24:37 +0800

1. 主从模式

1.1 同步复制

        对于关系型数据库，同步或者异步通常是一个可选项，而其他系统可能是硬性指定二选一。
        同步复制的优点是：一旦向用户确认，从节点可以保证已经完成了与主节点的同步，数据已经处于最新版本。如果主节点发生故障，总是可以确保之后继续访问从节点的数据一定是最新的。缺点是：如果同步的从节点无法确认成功，整个写入就不能成功，主节点会阻塞之后的所有写操作，直到同步副本确认。由于该缺点的存在，把所有从节点都配置为同步复制有些不切实际。在实践中，如果数据库启用了同步复制，通常意味着其中某个从节点是同步的，其他从节点则是异步的。如果同步的从节点不可用或者性能下降，则将另一个从节点升级为同步。这样可以保证至少有两个节点拥有最新的数据，这种配置也被称为半同步。
        在主从模式下，如果要提高读性能，需要添加更多的从节点。但是，这种方式实际上只能用于异步模式，因为随着从节点的增加，全同步模式需要同步的从节点数量也会增加，任何单节点的故障或者网络中断都会导致整个集群无法写入，节点的增加也会提高故障机率，所以全同步模式在实践中是非常不可靠的。

1.2 异步复制

        主从复制通常会被配置为全异步模式。此时，如果主节点失败且不可恢复，则所有尚未同步的从节点的写请求都会丢失，即使已经向客户端确认了写操作完成，仍然无法保证数据的持久化。全异步模式的优点是，不管从节点的数据多么滞后，总是可以继续响应写请求，具有较高吞吐性。异步模式听起来很不靠谱，但是却被广泛使用，特别是那些从节点数据巨大，或者分布于广域地理环境的情况。
        异步模式下节点的数据同步可能存在滞后，意味着对主节点和从节点同时发起相同的查询，返回的结果可能是不一致的。但是，这种不一致只是暂时的状态，在不写数据库的情况下，从节点最终会与主节点的数据保持一致，这种效应也被称为最终一致性。
        理论上，复制的滞后并没有上限。正常情况下，这个延迟可能不到 $1s$ ，实践中通常不会有太大影响。但是，如果系统的性能抵达上限，或者存在网络问题，延迟可能会达到几秒甚至几分钟。

1.2.1 读写一致性

许多应用让用户提交数据，并在之后查询这些数据。用户向主节点提交数据后，之后的查询可能是在从节点上，在大多数情况下，这是个很合适的方案。然而，异步模式下，同步可能存在滞后，意味着，返回的数据是旧数据，在用户看来，代表他刚刚提交的数据丢了。
这种情况，我们需要读写一致性，或者叫写后读一致性。该机制保证，如果用户重新加载页面，总是能看到最近提交的更新。有几种方式可以实现读写一致性：

如果用户访问可能会被修改的内容，从主节点读取。这种方式要球一些方法在执行实际查询前，就知道内容是否改变。比如，社交网络上的用户信息通常只能由所有者编辑，因此，可以让用户总是从主节点读取自己的用户信息，从节点读其他人的用户信息；
如果应用的大部分内容都可以被所有用户修改，这种方式就不太有效了。此时需要其他方式来判断，比如跟踪更新时间，在更新后的一分钟内，总是从主节点读取；或者监控从节点的复制滞后程度，避免从滞后超过一分钟的从节点读取数据；
客户端记录最近更新的时间戳，附带在请求中，节点可以通过该时间戳确保返回该时间戳之后的更新，如果无法返回，交由另外一个节点处理。时间戳可以是逻辑时间戳 ( 比如日志序列号 ) 或者实际系统时间；
如果副本分布在多个数据中心，这时情况会比较复杂，应当将请求路由到主节点所在的数据中心，即使该数据中心可能离用户距离很远。

如果同一用户从多端访问 ( 比如Web端和移动端 )，情况就更加复杂了，不仅要提供跨设备的读写一致性，还有新问题：

时间戳方式难以实现，因为一台设备并不知道另一台设备的操作，如果需要实现时间戳方式，元数据需要做到全局共享；
如果副本分布在多数据中心，无法保证来自不同设备的连接路由到同一个数据中心。

1.2.2 单调读

假定用户发起多次读取，读请求可能会被路由到不同节点，则可能会出现请求返回不同结果的情况。单调读一致性可以确保不会发生这种异常。单调读一致性比强一致性弱，但是比最终一致性强。读取数据时，单调读保证同一个用户一次发起的多次读取不会看到回滚 ( 数据不一致 ) 现象。一种实现单调读的方式是：确保每个用户总是固定读同一个节点，例如基于用户ID哈希。

1.2.3 前缀一致读

用户发起两个请求，后一个请求的内容依赖于前一个请求，比如用户先写入 $1$ ，再递增为 $2$ 。从用户的角度，这个顺序没有问题。但是在其他观察者的角度，可能会存在逻辑问题，比如由于网络延迟，观察者先观察到后一个请求，这时顺序就变成了用户先写入 $2$ ，再写入 $1$ 。为了防止这种异常，需要引入前缀一致性，即对于一系列按照某个顺序发起的写请求，读取的时候也应该按照这个顺序。
这个问题是存在于分区数据库的一个特殊问题。如果数据库总是以相同的顺序写入，那么读取的时候看到的会是一致的序列。但是，分区数据库的不同分区之间是独立运行的，所以没有一个全局的写入顺序，导致用户读取的时候，会读到一部分新值和一部分旧值。一种解决方案是：将所有具有因果关系的写入都交给同一个分区完成，但是会导致效率大打折扣。

1.3 节点失效

1.3.1 从节点失效

从节点的磁盘上保存了数据变更日志，如果从节点崩溃，或者与主节点之间发生暂时性的网络中断，可以通过该日志获取故障前处理的最后一个事务，向主节点请求该事务之后的中断期内所有数据变更，将其应用到本地即可，之后就可以像正常情况一样持续接收来自主节点的数据流变化。

1.3.2 主节点失效

主节点失效，则需要选择某个从节点，将其提升为主节点。同时，客户端也要将之后的写请求发送给新的主节点。故障切换可以是手动的，也可以是自动的，自动切换的步骤如下：

确认主节点失效。主节点可能出于多种原因失效，比如系统崩溃、停电、网络中断等，并没有什么办法可以检测出失效原因，所以大多数系统都采用了超时机制判断。节点间会持续地互相发送心跳消息，如果发现某个节点在一段时间 ( 比如 $30s$ ) 内都没有响应，就认为该节点已经失效；
选举新的主节点。新的主节点可以通过一种共识算法来选举，或者由控制节点指定。候选节点最好是与主节点之间数据差异最小的，从而最小化数据丢失的风险；
重新配置系统使得新主节点生效。客户端需要将写请求发送给新的主节点，如果原来的主节点之后重新上线，需要将其降级为从节点，并认可新的主节点。

切换过程中可能存在很多变数：

如果使用异步复制，新的主节点相比原主节点的数据存在滞后，在选举完成后，原主节点又很快恢复并加入集群，接下来的写操作要怎么处理？新的主节点可能会收到冲突的写请求，因为原主节点并没有意识到发生了主节点切换，仍然会尝试同步其他从节点。一种常见的解决方案是，直接丢弃这些冲突的写请求，虽然这会违背数据更新持久化的承诺；
如果有其他依赖于数据库的组件在一起协同使用，丢弃数据的方案就很危险。例如，在GitHub的一个事故中，主节点在未完全同步的情况下失效，新主节点被选举，由于存在滞后，原主节点已经分配出去，存储在Redis中的自增主键，被新主节点再次使用，导致了MySQL与Redis之间的数据不一致；
某些情况下，可能会发生两个节点都认为自己是主节点的情况，称为脑裂。脑裂非常危险，它可能会导致两个主节点同时接收写请求，并且没有很好的解决数据冲突，导致数据被丢失或者被破坏。有些系统会通过强制关闭其中一个节点的方式，来解决脑裂问题。然而，如果设计或者实现考虑不周，也是有可能出现两个节点都被关闭的情况；
如果设置超时时间？超时时间越厂，确认主节点失效的时间也就越长，意味着总体的恢复时间就越长。例如，突发的负载峰值会导致节点的响应时间变长甚至超时，或者由于网络故障导致延迟增加，如果这时系统已经处于高负载情况，或者网络严重拥堵的情况，不必要的切换只会使情况更糟。

1.4 日志

1.4.1 语句复制

主节点记录执行的写请求语句，将该操作语句作为日志，发送给从节点。在关系型数据库中，意味着发送 $INSERT$ 、$UPDATE$ 等语句，从节点分析并执行这些语句，像来自客户端那样。基于语句复制存在一些不适用场景：

C++ Templates（6）：模版实践与泛型库

Mon, 14 Mar 2022 15:57:27 +0800

1. 包含模式

1.1 链接错误

大部分C/C++程序员通常以这种方式组织非模版代码：

类和其他类型声明在头文件中；
全局变量和非内联函数只在头文件中声明，定义在另一个单独的翻译单元中。

这种方式让类型定义在整个程序中可用并且避免了链接过程中重复定义的错误。在这种方便方式的前提下，很多初学模版的程序员会对将定义声明在头文件中的方式感到抱怨。如果我们将模版函数的声明和定义分开：

#ifndef MYFIRST_HPP
#define MYFIRST_HPP

template<typename T>
void printTypeof(T const&);

#endif // MYFIRST_HPP

#include <iostream>
#include <typeinfo>
#include "myfirst.hpp"

template<typename T>
void printTypeof(T const& x) {
  std::cout << typeid(x).name() << '\n';
}

#include "myfirst.cpp"

int main() {
  double ice = 3.0;
  printTypeof(ice);
}

C++编译器很可能会编译这个程序，但是链接器会产生错误，错误为没有 $printTypeof$ 函数的定义。这个错误的原因是函数模版的定义无法被实例化。要实例化一个模版，编译器必须知道应该实例化哪些定义以及哪些模版参数应该被实例化。不幸的是，在上面的例子中，这两个信息都被单独编译了。因此，当我们的编译器想实例化 $printTypeof$ 的调用但是没有看到定义时，它只能假设这个定义在别处被提供了并且创建了一个引用 ( 给链接器解析 )。另一方面，当编译器处理 $myfirst.cpp$ 文件时，并没有任何提示说明它应该实例化出特定类型参数的模版定义，从而链接器无法解析出先前创建的引用。

1.2 头文件中的模版

之前问题的通用解决方案是采用与宏和内联函数相同的方式：在头文件中定义声明的模版。

#ifndef MYFIRST_HPP
#define MYFIRST_HPP

#include <iostream>
#include <typeinfo>

template<typename T>
void printTypeof(T const&);

template<typename T>
void printTypeof(T const& x) {
  std::cout << typeid(x).name() << '\n';
}

#endif // MYFIRST_HPP

        这种组织模版的方式称为包含模式。通过这种方式，程序现在可以正常编译、链接和执行了。
        这里有几点我们要注意下。最重要的一点是这种方式使得包含头文件的开销变得相当大。在这个例子中，开销主要不是来源于模版定义的代码体积，而是我们在定义模版的过程中使用的其他两个头文件—— $iostream$ 和 $typeinfo$ 。你会发现这两个头文件中有着一大堆代码，因为它们本身也有着很多模版定义。
        在实践中，这个问题很重要，因为它会导致一些重要程序的编译时间增加。因此，我们将通过一些可行的方法来解决这个问题，包括预编译头和显式模版特例化。尽管存在编译时间问题，我们还是推荐使用包含模式来组织你的模版，直到有新的更好的机制推出。模块 ( $modules$ ) 在C++20被引入，这是一种允许程序员以更加逻辑化的方式组织代码的机制，通过它，编译器可以独立编译所有声明并且之后可以在需要的时候选择性地高效地导入处理好的声明。
        另一个要注意的点是包含模式下非内联模版函数和内联函数以及宏是不同的，它们不会在被调用时展开。相反，当它们被实例化时，会创建一个函数副本。因为这是自动进行的，编译器可能会在两个不同的文件中创建相同的副本。理论上，这不应该由我们来关心，这是C++编译系统该关心的。工程上这种方式大部分时候是可以的，我们完全不需要解决这个问题。对于大型项目，当它们创建自己的代码库，这个问题可能偶尔会出现。
        最后，我们还要注意在上面的例子中，适用于普通函数模版的方式，也适用于类模版中的成员函数和静态数据成员，同样也适用于成员函数模版。

C++ Templates（5）：编译时编程

Mon, 14 Mar 2022 12:33:51 +0800

1. 模版元编程

模版在编译期实例化，这使得一些C++模版特性可以在实例化阶段进行一系列递归的语言编程。所以，我们可以使用模版来作为程序计算。

template<unsigned p, unsigned d>
struct DoIsPrime {
  static constexpr bool value =
    (p % d != 0) && DoIsPrime<p, d - 1>::value;
};

template<unsigned p>
struct DoIsPrime<p, 2>{
  static constexpr bool value = (p % 2 != 0);
};

template<unsigned p>
struct IsPrime {
  static constexpr bool value =
    DoIsPrime<p, p / 2>::value;
};

template<>
struct IsPrime<0> {
  static constexpr bool value = false;
};

template<>
struct IsPrime<1> {
  static constexpr bool value = false;
};

template<>
struct IsPrime<2> {
  static constexpr bool value = true;
};

template<>
struct IsPrime<3> {
  static constexpr bool value = true;
};

上面的代码计算一个数是否为质数。$DoIsPrime$ 会递归地展开表达式。例如：

IsPrime<9>::value

会展开为：

DoIsPrime<9, 4>::value

然后按照以下顺序继续展开：

9 % 4 != 0 && DoIsPrime<9, 3>::value

9 % 4 != 0 && 9 % 3 != 0 && DoIsPrime<9, 2>::value

9 % 4 != 0 && 9 % 3 != 0 && 9 % 2 != 0

从而得到 $false$ ，于是 $9$ 不是质数。
注意所有的这些运算都会在编译期完成。虽然模版语法很丑，但是它在一些库中被证实是有效的。

C++ Templates（4）：移动与引用

Sun, 13 Mar 2022 14:27:10 +0800

1. 移动语义

C++11的一个最突出的特性的就是移动语义，它对模版设计有着显著的影响。

1.1 完美转发

假设你想要编写泛型代码，转发参数的基本属性：

可变对象必须被转发，这样它们就能被继续修改；
常量对象应该被转发为只读对象；
可移动对象应该继续被转发为可移动对象。

为了在不使用模版的前提下实现这个功能，我们需要编写三种情况的代码。

#include <utility>
#include <iostream>

class X {};

void g(X&) { std::cout << "g() for variable\n"; }

void g(X const&) { std::cout << "g() for constant\n"; }

void g(X&&) { std::cout << "g() for movable object\n"; }

void f(X& val) { g(val); }

void f(X const& val) { g(val); }

void f(X&& val) { g(std::move(val)); }

注意可移动对象的代码需要使用 $std::move$ ，因为当它们作为表达式使用时会被视为左值。
如果我们想要使用泛型代码，就会出现这种问题：

template<typename T>
void f(T& val) { g(val); }

上面这种形式的代码只会匹配前两种情况，不会匹配可移动对象。出于这个原因，C++11引入了完美转发参数。

template<typename T>
void f(T&& val) { g(std::forward<T>(val)); }

注意这里使用了 $std::forward$ ，它是一个模版。不要认为模版函数中的 $T$&& 行为与非模版的 $X$&& 相同，从语法上来看，它们分别代表：

$X$&& 是一个类型为 $X$ 的右值引用参数，只能绑定到可移动对象上，总是可变和可移动的；
$T$&& 是一个声明为转发引用 ( $forwarding$ $reference$ ) 的模版参数 ( 也被称为通用引用 ( $universal$ $reference$ ) 。它可以绑定到可变对象、不可变对象或者可移动对象。在函数定义内，参数可以是可变的、不可变的或者可移动的。

$T$ 必须是一个模版参数，仅仅在模版内声明是不够的，比如 $typename$ $T::iterator$&& 就仅仅是一个右值引用，而不是转发引用。

C++ Templates（3）：基本技术

Sat, 12 Mar 2022 17:53:20 +0800

1. `typename`

关键字 $typename$ 用于标识模版内部的某个成员是一个类型。

template<typename T>
class MyClass {
public:
  void foo() {
    typename T::SubType* ptr;
  }
};

这里的第二个 $typename$ 就是用于标识 $SubType$ 是一个类型。如果没有 $typename$ ，$SubType$ 就必须是一个非类型成员，从而表达式会变成乘法运算，这会导致一个错误。
$typename$ 的一个应用是在泛型类中声明迭代器：

#include <iostream>

template<typename T>
void printcoll(T const& coll) {
  typename T::const_iterator pos;
  typename T::const_iterator end(coll.end());
  for (pos = coll.begin(); pos != end; ++pos) {
    std::cout << *pos << ' ';
  }
  std::cout << '\n';
}

2. 零初始化

对于基本类型，例如 $int$ 、$double$ 或指针类型，它们没有默认构造函数，意味着初始化时必须被赋予一个初始值，否则它们的值就是不确定的。假设你有一个模版变量，并且想要让它拥有初始值，但是内置类型并不会初始化。出于这个原因，你可以显式初始化，这会让它们的值变为 $0$ ：

template<typename T>
void foo { T x{}; }

这种初始化称为值初始化，表示要么调用一个已提供的构造函数，要么进行零初始化。这种方式甚至对 $explicit$ 构造函数也生效。
C++11之前，使用零初始化的方式是小括号：

T x = T();

在C++17之前，只有拷贝初始化的构造函数不是 $explicit$ 时才能使用这个机制，C++17强制性的拷贝省略避开了这种限制。如果类没有默认构造函数，那么也可以通过花括号调用初始化列表构造函数。

3. 原始数组和字符串常量模版

当给模版参数传递原始数组和字符串常量时，有些问题要注意。首先，如果模版参数声明为引用，那么推导出来的参数是未退化的。只有当模版参数是值传递时，才会发生类型退化，这时原始数组和字符串常量都会退化为指针。

template<typename T, int N, int M>
bool less(T (&a)[N], T (&b)[M]) {
  for (int i = 0; i < N && i < M; i++) {
    if (a[i] < b[i]) return true;
    if (b[i] < a[i]) return false;
  }
  return N < M;
}

std::cout << less("ab", "abc") << std::endl;

在上面的例子中，$T$ 是 $char$ $const$ ，$N$ 和 $M$ 分别是 $3$ 和 $4$ 。
如果你只是想要为字符串常量提供一个模版，那么你可以这样：

C++ Templates（2）：非类模版参数

Sat, 12 Mar 2022 14:57:44 +0800

1. 非类模版参数

1.1 非类模版参数类

你可以实现一个固定大小的 $Stack$ ，这样就可以避开内存管理的开销。为了让 $Stack$ 更加灵活，你可以让用户决定最大大小。

#include <array>
#include <cassert>

template<typename T, std::size_t Maxsize>
class Stack {
private:
  std::array<T, Maxsize> elems;
  std::size_t numElems;

public:
  Stack();
  void push(T const& elem);
  void pop();
  T const& top() const;
  bool empty() const { return numElems == 0; }
  std::size_T size() const { return numElems; }
};

template<typename T, std::size_t Maxsize>
Stack<T, Maxsize>::Stack() : numElems(0) {}

template<typename T, std::size_t Maxsize>
void Stack<T, Maxsize>::push(T const& elem) {
  assert(numElems < Maxsize);
  elems[numElems] = elem;
  ++numElems;
}

template<typename T, std::size_t Maxsize>
void Stack<T, Maxsize>::pop() {
  assert(!elems.empty());
  --numElems;
}

template<typename T, std::size_t Maxsize>
T const& Stack<T, Maxsize>::top() const {
  assert(!elems.empty());
  return elems[numElems - 1];
}

$Maxsize$ 的类型是 $int$ ，它指定了 $Stack$ 内部 $array$ 成员的大小。此外，它也用于 $push$ 函数中检查栈是否已满。
你也可以指定一个默认类型和大小：

template<typename T = int, std::size_t Maxsize = 100>
class Stack;

然而，这不是一个好设计。默认值应该是一个符合直觉且正确的值，但是不管是 $int$ 还是 $100$ 都不够通用。所以，最好还是把这些交给用户决定。

1.2 非类模版参数函数

你也可以为函数定义非类模版参数。

C++ Templates（1）：函数模版和类模版

Fri, 11 Mar 2022 14:03:16 +0800

前面都是一些基础概念，快速过一下。

1. 函数模版

函数模版提供了一种可以被不同类型调用的函数行为。换句话说，函数模版表示一组类似的函数。它的表现类似于普通函数，除了一些元素类型未指定。

template<typename T>
T max(T a, T b) {
  return b < a ? a : b;
}

std::cout << max(1, 2) << std::endl;  // 2

关键字typename声明了一个类型参数 $T$ ，由于历史原因，你也可以使用class关键字声明。$T$ 表示一个任意类型，会根据不同的调用而改变。在上面的例子中，类型 $T$ 必须支持 $operator$< 函数并且可拷贝。C++17也允许在 $T$ 既不可拷贝也不可移动的情况下传入一个右值。在上面的例子中，$T$ 的类型是 $int$ 。将模版参数用具体类型代替的过程称为实例化 ( $instantiation$ )，实例化会产生一个模版实例。
注意到 $void$ 也可以作为模版参数：

template<typename T>
T foo(T*) {}

void *vp = nullptr;
foo(vp);

模版会进行两阶段编译：

定义阶段 ( $definition$ $time$ )，即没有实例化的阶段，编译器会检查模版代码是否正确，包括语法检查、调用检查、$static_-assert$ 等；
实例化阶段 ( $instantiation$ $time$ )，模版代码会被再次检查，这次包括了所有依赖于模版参数的部分。

有些编译器并不会在定义阶段进行完全检查，这意味着有些问题只有在实例化的时候才能发现。
在类型推导时，如果存在隐式类型转换，那么会应用以下规则：

当参数以引用传递时，即使是一些普通的转换也不能进行参数推导，使用相同模版参数类型 $T$ 的参数类型必须一致；
当参数以值传递时，只支持一些普通的类型退化 ( $decay$ )，包括：忽略 $const$ 或 $volatile$ 、引用转化为非引用以及数组或函数转为裸指针。在这种情况下，使用相同模版参数类型 $T$ 的参数类型必须在进行参数退化后保持一致。

函数模版类型推导也不支持默认参数：

template<typename T>
void f(T = "");

f();  // 错误

正确的使用方式如下：

EffectiveModernCpp（7）：通用技巧

Sun, 06 Mar 2022 17:28:50 +0800

C++中的通用技巧总是存在适合使用的场景和不适合使用的场景。描述一个适合使用某项通用技巧的场景通常是很简单的，但是也存在两个例外。接下来会描述这两个例外。

1. 值传递

有些函数的参数是可以拷贝的。

class Widget {
public:
  void addName(const std::string &newName) {
    names.push_back(newName);
  }
  void addName(std::string &&newName) {
    names.push_back(std::move(newName));
  }

private:
  std::vector<std::string> names;
};

对于左值，我们调用拷贝构造函数，而对于右值，我们调用移动函数。这很合理，但是有点难受，因为我们要重载这个函数，这意味着更多的代码、更多的文档。我们可以使用通用引用改善这个问题：

class Widget {
public:
  template<typename T>
  void addName(T &&newName) {
    names.push_back(std::forward<T>(newName));
  }

// ...
};

但是，正如我们之前所说的，通用引用也会带来新问题。而且，因为它是模版函数，所以定义也要放在头文件中。在模版函数实例化的过程中，根据类型的不同，这个函数也会实例化很多个版本。
既然如此，我们能不能只用一个函数解决这个问题？答案是使用值传递。

class Widget {
public:
  void addName(std::string newName) {
    names.push_back(std::move(newName));
  }

// ...
};

因为 $newName$ 是通过值传递的，这意味着它是一个副本，所以我们可以使用移动。但是值传递会不会带来效率问题？在C++98中，可以肯定的是 $newName$ 在传递过来的时候已经经过一次拷贝了。然而在C++11中并不是，它可能是左值拷贝或者右值移动。

Widget w;
std::string name("Bart");
w.addName(name);  // 左值
w.addName(name + "Jenne");  // 右值

在第一次调用中，因为参数是左值，所以调用了一次拷贝构造函数。但在第二次调用中，因为参数是右值，所以调用的是移动构造函数。
回顾我们之前列举的三种方式，比较一下它们的开销：

重载版本：在重载版本中，参数传递不会带来开销，但是在 $push_-back$ 的时候存在开销，分别是一次拷贝和一次移动；
通用引用：同样的，参数传递没有开销，但是在 $push_-back$ 的时候存在开销，也是一次拷贝和一次移动；
值传递：无论是左值还是右值，都必须构造一次 $newName$ ，分别对应一次拷贝和一次移动。在之后的 $push_-back$ 调用中还需要进行一次移动。

总结下来，值传递方式总是会多一次移动操作。但是根据我们之前所说的，移动操作的开销很低，所以问题不是很大，而且这种方式也可以有效避免代码膨胀。
当然，使用值传递是有前提的：

只对存在拷贝函数的对象使用。如果函数没有拷贝函数，那么我们只需要一个接收右值的函数即可；
只对移动操作开销小的对象使用；
只对肯定会进行拷贝/移动的参数使用。如果函数不一定会进行拷贝/移动操作，那么值传递会带来不必要的开销。

class Widget {
public:
  void addName(std::string newName) {
    if ((newName.length() >= minLen) &&
        (newName.length() <= maxLen)) {
      names.push_back(std::move(newName));
    }
  }

private:
  std::vector<std::string> names;
};

这种情况下参数不一定会被拷贝/移动，如果没有发生拷贝/移动，那么它相比其他模式就多了一次拷贝。
即使你的函数处理的是一个移动比拷贝开销小的对象，值传递也不一定更合适，因为对象复制存在两种方式，一种是构造函数，另一种是赋值运算符。在上面的例子中，我们使用的是构造函数。让我们分析下使用运算符的情况：

EffectiveModernCpp（6）：并发

Sat, 05 Mar 2022 16:29:15 +0800

C++11的最伟大标志之一是将并发整合到语言和库中，允许开发者通过标准库写出跨平台的多线程程序。

1. `std::async`

如果开发者想要异步执行 $doAsyncWork$ 函数，有两种方式，一种是创建 $std::thread$ ：

int doAsyncWork();
std::thread t(doAsyncWork);

另一种是创建 $std::async$ ：

auto fut = std::async(doAsyncWork);

通常我们会选择第二种方法，一是因为它代码量更少，二是可以获取返回值。更进一步，如果 $doAsyncWork$ 发生异常，我们还可以通过 $get$ 获取异常。
基于线程与基于任务的最根本区别在于抽象层次的高低。基于任务的方式将开发者从线程管理中解放出来。C++的线程有三种含义：

硬件线程 ( $Hardware$ $threads$ )，即计算机真正执行计算的线程，每个CPU核心都会提供一个或多个硬件线程；
软件线程 ( $Software$ $threads$ )，是操作系统管理的在硬件线程上执行的线程。通常情况下，软件线程的数量会大于硬件线程；
$std::thread$ ，是C++执行过程的对象，作为软件线程的句柄。

        软件线程是有限的，如果你创建的软件线程的数量大于计算机最大能提供的数量，会抛出 $std::system_-error$ 错误。即使线程调用的函数是 $noexcept$ 的，这个错误依然会发生。
        设计良好的程序必须避免这种错误，一种有效的方法是在当前线程执行 $doAsyncWork$ ，但是这可能会导致负载不均衡，尤其是当前线程是GUI线程的时候，程序可能会陷入长时间未响应的状态；另一种办法是等待当前线程结束后再新创建线程，但是如果当前线程在等待 $doAsyncWork$ 的结果，这时程序就会陷入死锁。
        即使我们没有超出最大线程数，可用资源也会约束我们的程序。如果当前软件线程数大于硬件线程数，就会发生上下文切换。线程的上下文切换会带来开销，如果这时软件线程运行的CPU核心与之前的硬件线程所在的核心不同，这个开销会更高，因为(a)CPU缓存需要重新载入；(b)新线程缓存会覆盖老线程缓存，导致老线程再次在当前核心运行时又要重新载入缓存。
        避免这种资源开销的问题是很难的，因为软件线程与硬件线程的最佳比例取决于软件线程的执行效率，一个很明显的例子就是计算密集型程序和I/O密集型程序的执行效率是不同的。这个比例还依赖于上下文切换的开销和CPU缓存的使用效率。而且，对某种类型硬件和平台进行优化并不意味着换种硬件或者平台依然还有着这种效率。
        相比于直接使用 $std::thread$ ，$std::async$ 可以把调整最优线程数量的工作交给标准库实现，而且也可以减少资源超额的可能。$std::async$ 并不保证开启一个新线程，只是保证会执行该函数。我们也可以选择性地通过调用程序让它在当前线程执行。如果在GUI程序中使用 $std::async$ 出现了相应变慢的问题，我们还可以通过 $std::launch::async$ 来指定调度策略。
        最新的线程调度算法会使用线程池来避免资源问题，并且通过工作窃取算法提升跨核心的负载均衡。C++标准库虽然没有要求使用线程池或者工作窃取算法，但是库开发者们在标准库中使用了这些技术。使用基于任务的开发模式，处理资源和负载均衡的问题就交给了库开发者，而如果使用基于线程的开发模式，这些工作就落在了我们头上，更不用说还要考虑跨平台问题了。
        当然，这不意味着 $std::async$ 总是比 $std::thread$ 好。在一些场景中，$std::thread$ 是更好的选择：

需要访问非常基础的线程API。C++的并发API通常是通过操作系统提供的系统级API ( $pthreads$ 或者 $windows$ $threads$ ) 来实现的。系统级API允许更加灵活的操作方式，例如优先级。为了提供对底层系统级API的访问，$std::thread$ 提供了 $native_-handler$ 成员函数，而 $std::async$ 没有；
需要优化应用线程调度。对于一些特定系统平台运行的程序，经过优化，可以比C++标准库更有效率；
需要实现C++并发API之外的线程技术，例如自己实现一个线程池。

2. 启动策略

当调用 $std::async$ 时，你通常希望该函数被异步执行，但它不一定会这样做。$std::async$ 有两种策略，通过 $std::launch$ 域的枚举表示：

EffectiveModernCpp（5）：Lambda

Sat, 05 Mar 2022 13:29:53 +0800

Lambda可以做的事情都可以通过其他方式完成，它的作用是简化我们的编写。对于标准库中的许多 $if$ 算法 ( $std::find_-if$ 、$std::remove_-if$ 等 ) ，它们通常需要繁琐的谓词。但是通过lambda表达式，这些算法的使用就变得非常方便。
闭包 ( $closure$ ) 是lambda创建的运行时对象，根据捕获模式，闭包会持有捕获数据的副本或者引用。闭包类 ( $closure$ $lcass$ ) 是从闭包中实例化出的类。每个lambda都会生成唯一的闭包类。lambda中的语句是闭包类成员函数中的指令。

1. 捕获模式

C++11有两种默认的捕获模式：引用捕获和值捕获。引用捕获会带来悬垂引用问题，值捕获可能会让你觉得能解决悬垂引用问题 ( 但是并不能 )，还会让你觉得你的闭包是独立的 ( 实际上也不是 )。
引用捕获会导致闭包中包含了对局部变量或者某个形参的引用，如果该lambda的生命周期超过了局部变量的生命周期，那么闭包中将出现悬垂引用。

using FilterContainer =
  std::vector<std::function<bool (int)>>;
FilterContainer filters;

void addDivisorFilter() {
  auto calc1 = computeSomeValue1();
  auto calc2 = computeSomeValue2();
  auto divisor = computeDivisor(calc1, calc2);
  filters.emplace_back(
    [&](int value) { return value % divisor == 0; }
  );
}

这个代码是一个定时炸弹。$divisor$ 的生命周期在 $addDivisorFilter$ 返回时就结束了，这会导致 $filters$ 出现未定义行为。
一个解决问题的办法是值捕获。

filters.emplace_back(
  [=](int value) { return value % divisor == 0; }
);

这可以解决上面例子的问题。但是要注意，通常情况下，值捕获并不能完全解决悬垂引用的问题。假设你捕获的是指针，随着函数结束，指针指向对象被删除，这还是会导致指针悬垂。

class Widget {
public:
  // ...
  void addFilter() const;

private:
  int divisor;
};

void Widget::addFilter() const {
  filters.emplace_back(
    [=](int value) { return value % divisor == 0; }
  );
}

这个代码看起来好像正确，lambda成功捕获了 $divisor$ 。我们换种写法再来看看：

EffectiveModernCpp（4）：引用

Fri, 04 Mar 2022 14:04:32 +0800

1. `move`和`forward`

$std::move$ 和 $std::forward$ 理论上什么都没有做，仅仅是负责转换。

template<typename T>
typename remove_reference<T>::type &&
move(T &&param) {
  using ReturnType =
    typename remove_reference<T>::type &&;

  return static_cast<ReturnType>(param);
}

以上为C++11的 $std::move$ 示例实现，尽管不完全满足标准，但是已经十分接近了。$std::move$ 接受一个对象引用，返回一个指向同一对象的引用。&& 表示 $std::move$ 返回一个右值引用，但是由于引用折叠的存在，为了防止其被折叠为左值引用，我们使用了 $std::remove_-reference$ 。
$std::move$ 可以在C++14中以更简单的方式实现。

template<typename T>
decltype(auto) move(T &&param) {
  using ReturnType = remove_reference_t<T> &&;
  return static_cast<ReturnType>(param);
}

假设你有一个类，它用于表示一段注解：

class Annotation {
public:
  explicit Annotation(std::string text);
  // ...
};

考虑到你需要的只是读取 $text$ ，并不用修改，所以你自然而然地想到 $const$ ：

class Annotation {
public:
  explicit Annotation(const std::string text);
  // ...
};

这里你可能会想到使用移动操作，因为你的入参是值方式传递的：

class Annotation {
public:
  explicit Annotation(const std::string text)
    : value(std::move(text)) {}
  // ...
private:
  std::string text;

可惜的是，这里的 $text$ 并不是移动过去的，而是拷贝过去的。要理解这个问题，我们可以看一下 $std::string$ 的构造函数：

class string {
public:
  string(const string &rhs);
  string(string &&rhs);
  // ...
};

问题的关键就在于 $std::string$ 的移动构造函数接收一个非常量，而我们之前传递的是常量。思考以下也可以理解，因为我们无法修改常量，自然也就无法移动了。
$std::forward$ 是有条件的转换。

EffectiveModernCpp（3）：智能指针

Thu, 03 Mar 2022 13:38:11 +0800

智能指针包裹了原始指针，行为类似于被包裹的原始指针，但是避免了原始指针的很多陷阱。C++11中存在四种智能指针：

$std::auto_-ptr$ ；
$std::unique_-ptr$ ；
$std::shared_-ptr$ ；
$std::weak_-ptr$ 。

它们都是设计于帮助管理动态分配的对象生命周期的，会在适当的时间通过适当的方式销毁对象，避免出现资源泄露或者异常行为。
$std::auto_-ptr$ 是C++98的遗留，C++11使用 $std::unique_-ptr$ 替代了它。$std::unique_-ptr$ 在 $std::auto_-ptr$ 的基础上可以做更多的事情，在任何方面都比 $std::auto_-ptr$ 好。

1. `unique_ptr`

        当你需要一个智能指针的时候，$std::unique_-ptr$ 通常是最适合的。默认情况下，$std::unique_-ptr$ 等同于原始指针，并且对于大部分操作，它们的操作完全相同。
        $unique_-ptr$ 体现了专有语义，一个非空的 $unique_-ptr$ 始终持有其指向的内容。在这个前提下，移动拷贝会转移指针的所有权，拷贝操作则是完全不允许的。当 $unique_-ptr$ 销毁时，它会调用其关联的析构函数。
        $unique_-ptr$ 的常见用法是作为对象工厂函数的返回值。

class Investment {};
class Sock: public Investment {};
class Bond: public Investment {};
class RealEstate: public Investment {};

template <typename ...Ts>
std::unique_ptr<Investment>
makeInvestment(Ts&&... params);

默认情况下，$unique_-ptr$ 持有指针的销毁通过 $delete$ 进行，但是也可以自定义一个析构函数。如果创建的对象需要在析构前写一条日志，可以这样实现：

auto delInvmt = [](Investment *pInvestment) {
  makeLogEntry(pInvestment);
  delete pInvestment;
};

template <typename ...Ts>
std::unique_ptr<Investment, decltype(delInvmt)>
makeInvestment(Ts&&... params) {
  std::unique_ptr<Investment, decltype(delInvmt)>
  pInv(nullptr, delInvmt);

  if (/* a Stock object should be created */)
    pInv.reset(new Stock(std::forward<Ts>(params)...));
  else if (/* a Bond object should be created */)
    pInv.reset(new Bond(std::forward<Ts>(params)...));
  else if (/* a RealEstate ojbect should be created */)
    pInv.reset(new RealEstate(std::forward<Ts>(params)...));
  return pInv;
}

在上述代码中我们通过基类指针删除子类对象，这意味着基类的析构函数必须是虚析构函数。
当使用默认删除器时，我们可以假设 $unique_-ptr$ 的大小和原始指针相同。以函数指针的方式指定删除器时，通常会使 $unique_-ptr$ 的大小从一个字长增长为两个字长。对于删除器函数对象来说，函数中存储的状态数决定了其大小。如果一个函数没有状态 ( 比如没有捕获对象的lambda表达式 ) ，那么它也没有大小。从而如果我们使用无捕获的lambda函数来声明删除器，$unique_-ptr$ 的大小还是一个字长。

EffectiveModernCpp（2）：使用现代C++语法

Wed, 02 Mar 2022 14:09:12 +0800

1. 初始化

从不同的角度来看，C++11的初始化语法丰富却又混乱。

int w(0);  // 小括号初始化
int x = 0;  // =初始化
int y{0};  // 花括号初始化
int z = {0};  // =和花括号初始化

在通常情况下，后面两种是等价的。对于 $int$ 这种内置类型而言，这些初始化方式通常没有什么太大区别。但是对于用户类型而言，理解它们的区别很重要。

Widget w1;  // 默认构造函数
Widget w2 = w1;  // 拷贝构造函数
w1 = w2;  // 调用operator=

C++使用统一初始化 ( $uniform$ $initialization$ ) 来整合这些混乱的初始化语法。所谓统一初始化即使用单一初始化语法，是基于花括号的初始化。

std::vector<int> v{1, 3, 5};

std::atomic<int> ai1{0};
std::atomic<int> ai2(0);
std::atomic<int> ai3 = 0;  // 错误

class Widget {
  // ...
private:
  int x{0};
  int y = 0;
  int z(0);  // 错误
};

可以发现，相比于其他初始化方法，使用花括号的初始化方式在任何地方都成立，这也是为什么它被称为统一初始化。
花括号初始化还具备其他初始化不具有的特性——不允许内置类型的隐式变窄转换 ( $narrowing$ $conversion$ )。

double x, y, z;
int sum1(x + y + z);
int sum2 = x + y + z;
int sum3{x + y + z};  // 错误

此外，使用花括号初始化还可以避免C++的一个问题。这个问题的根源是C++规定所有能被认为是一个声明的语句都视为声明。从而会导致以下情况：

Widget w1(10);  // 初始化
Widget w2();  // 函数声明

本来是想调用默认构造函数的，结果却变成了一个函数声明。但是使用花括号初始化就不会有这个问题：

Widget w3{};  // 初始化

当然，花括号初始化也存在缺点，主要是与 $std::initializer_-list$ 相关的问题。

EffectiveModernCpp（1）：类型推导

Tue, 01 Mar 2022 15:15:57 +0800

1. 类型推导

考虑这样一个模版：

template<typename T>
void f(ParamType param);

f(expr);

编译器会使用 $expr$ 进行类型推导，一个是针对 $T$ 的，另一个是针对 $ParamType$ 的。这两个类型通常是不同的。例如：

template<typename T>
void f(const T &param);

int x = 0;
f(x);

这时 $T$ 被推导为 $int$ ，$ParamType$ 被推导为 $const$ $int$ & 。事实上，$T$ 的推导不仅取决于 $expr$ ，还取决于 $ParamType$ 。这里有三种情况：

$ParamType$ 是一个指针或引用，但不是通用引用；
$ParamType$ 是一个通用引用；
$ParamType$ 既不是指针也不是引用。

1.1 情况一

最简单的情况是 $ParamType$ 是一个指针或引用但不是普通引用，这时类型推导过程为：

如果 $expr$ 的类型是引用，忽略引用部分；
根据剩下部分推导 $T$ ，并得出 $ParamType$ 。

template<typename T>
void f(T &param);

int x = 27;
const int cx = x;
const int &rx = cx;

f(x); // T为int, ParamType为int &
f(cx);  // T为const int, ParamType为const int &
f(rx);  // T为const int, ParamType为const int &

注意第三个例子中，即使 $rx$ 是一个引用，$T$ 也会被推导为非引用。

Unix网络编程补充：eventfd和timerfd

Sat, 26 Feb 2022 17:30:49 +0800

1. `eventfd`

#include <sys/eventfd.h>

// 成功返回eventfd描述符， 出错返回-1
int eventfd(unsigned int initval, int flags);

$eventfd$ 调用返回一个 $eventfd$ 对象描述符，通过该描述符，进程可以在用户空间实现阻塞和唤醒机制，内核会负责唤醒阻塞在该描述符上的进程。$eventfd$ 对象包含一个无符号 $64$ 位整型计数器，由内核维护，初始化为 $initval$ 的值。$flags$ 值是以下值的或：

$flag$	说明
$EFD_-CLOEXEC$	设置该标志后，描述符将在 $execve$ 调用之后自动关闭
$EFD_-NONBLOCK$	非阻塞模式
$EFD_-SEMAPHORE$	为读提供类似于信号量的语义

对于Linux 2.6.26及以下的版本来说，$flags$ 参数没有作用且必须为 $0$ 。如果 $flags$ 参数非法，会返回 $EINVAL$ 错误。对于返回的描述符，可以进行以下操作：

$read$ ：调用成功会返回一个以主机字节序排列的 $64$ 位无符号整型；如果返回值小于 $64$ 位，则调用失败，返回 $EINVAL$ 错误。
- 如果没有指定 $EFD_-SEMAPHORE$ 并且 $eventfd$ 计数器值非零，$read$ 调用会返回计数器值，同时计数器值会被设置为 $0$ ；
- 如果指定了 $EFD_-SEMAPHORE$ 并且 $eventfd$ 计数器值非零，$read$ 调用会返回 $1$ ，同时计数器值会减一；
- 如果 $eventfd$ 计数器值为 $0$ ，$read$ 调用会阻塞直到计数器值非零。如果指定了 $EFD_-NONBLOCK$ ，$read$ 调用会返回 $EAGAIN$ 错误。
$write$ ：调用成功会为 $eventfd$ 计数器值加上一个 $64$ 位无符号整型的值的数量，最大为 $UINT_-MAX$ $-$ $1$ 。如果指定的值非 $64$ 位或者超过最大值，返回 $EINVAL$ 错误。
- 如果加上这个值会导致溢出，调用会阻塞直到该描述符被调用了一次 $read$ 。如果指定了 $EFD_-NONBLOCK$ ，$write$ 调用会返回 $EAGAIN$ 错误。
$poll$ / $select$ / $epoll$ ：
- 如果 $eventfd$ 计数器值大于 $0$ ，则描述符可读；
- 如果 $eventfd$ 计数器值至少可以加 $1$ ，则描述符可写；
- 如果 $eventfd$ 计数器值溢出，对于 $select$ ，该描述符状态会被设置为既可读也可写；对于 $poll$ ，返回 $POLLERR$ ；对于 $epoll$ ，返回 $EPOLLERR$ 。
$close$ ：递减该描述符的引用计数，当引用计数为零时，$eventfd$ 对象会被内核释放。

#include <sys/eventfd.h>

typedef uint64_t eventfd_t;

/* 成功返回调用传递的数据量，出错返回-1 */

int eventfd_read(int fd, eventfd_t *value);

int eventfd_write(int fd, eventfd_t value);

GNU C库定义了以上函数，与直接对 $eventfd$ 调用 $read$ 和 $write$ 的作用相同。

Unix网络编程补充：epoll

Fri, 25 Feb 2022 19:23:34 +0800

$epoll$ 执行与 $select$ 和 $poll$ 类似的工作：监听多个描述符，当其中存在可用描述符时返回。$epoll$ 支持边缘触发和层级触发两种模式，并且在监听大量描述符的情况下有着很好的性能。
$epoll$ 的核心是 $epoll$ 对象，这是一个内核数据结构，形式上，可以认为是两个集合：

监听集合 ( 有时候被称为 $epoll$ 集合 )：描述符集合，进程注册的新的待监听的描述符会被存放在该集合中；
可用集合：描述符集合，是监听集合的子集，内核通过该集合返回可用的文件描述符。

1. `epoll`操作

#include <sys/epoll.h>

/* 成功时返回0，出错返回-1 */

int epoll_create(int size);

int epoll_create1(int flags);

$epoll_-create$ 创建一个 $epoll$ 对象，返回该对象的描述符。从Linux 2.6.8开始，$size$ 参数不再有作用，会被忽略，但是必须大于 $0$ ，否则会设置 $EINVAL$ 错误。$epoll_-create1$ 与 $epoll_-create$ 类似，$flags$ 参数的值可以是 $EPOLL_-CLOEXEC$ ，当设置该标志时，该对象描述符会在执行 $execve$ 调用后自动关闭。

#inlcude <sys/epoll.h>

// 成功返回0，出错返回-1
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);

typedef union epoll_data {
  void *ptr;
  int fd;
  uint32_t u32;
  uint64_t u64;
} epoll_data_t;

struct epoll_event {
  uint32_t events;
  epoll_data_t data;
};

$epoll_-ctl$ 从 $epoll$ 描述符中添加、修改或删除事件，$fd$ 指定待监听的描述符。其中 $op$ 可以是：

Unix网络编程（20）：共享内存

Wed, 23 Feb 2022 13:45:30 +0800

共享内存是可用IPC形式中最快的。因为将内存区映射到进程的地址空间之后，进程间的数据传递就不用通过内核。

1. 共享内存操作

#include <sys/mman.h>

// 成功返回映射内存区的地址，出错返回MAP_FAILED
void *mmap(void *addr, size_t len, int prot, int flags, int fd, off_t offset);

$mmap$ 函数把一个文件或一个POSIX共享内存区对象映射到调用进程的地址空间。使用该函数有三个目的：

对普通文件使用内存映射I/O；
对特殊文件进行匿名内存映射；
使用 $shm_-open$ 提供无亲缘关系的进程间的POSIX共享内存区。

$addr$ 可以指定描述符 $fd$ 应该被映射到的进程内存空间的地址，也可以指定为 $NULL$ ，从而让内核自己选择。$len$ 是映射到调用进程地址空间中的字节数，从被映射字节开头第 $offset$ 个字节开始，$offset$ 可以为 $0$ 。内存映射区的保护由 $prot$ 参数提供，可选值有：

$prot$	说明
$PROT_-READ$	数据可读
$PROT_-WRITE$	数据可写
$PROT_-EXEC$	数据可执行
$PROT_-NONE$	数据不可访问

$prot$ 参数的常见值为 $PROT_-READ$ | $PROT_-WRITE$ 。$flags$ 指定共享内存属性，可选值有：

$flag$	说明
$MAP_-SHARED$	变动是共享的
$MAP_-PRIVATE$	变动是私有的
$MAP_-FIXED$	准确地解释 $addr$

其中 $MAP_-SHARED$ 和 $MAP_-PRIVATE$ 必须选择其中一个。如果选择 $MAP_-SHARED$ ，那么调用进程对映射区内所做的修改对其他进程可见，并且也会修改底层对象；如果选择 $MAP_-PRIVATE$ ，那么调用进程对映射区所做的修改只有当前进程可见，而且不会修改底层对象；从移植性上考虑，不应该指定 $MAP_-FIXED$ ，如果没有指定该标志并且 $addr$ 非空，则具体行为取决于实现。可移植的代码应该把 $addr$ 设置为 $NULL$ 并不指定 $MAP_-FIXED$ 。

Unix网络编程（19）：信号量

Mon, 21 Feb 2022 16:43:12 +0800

信号量 ( $semaphore$ ) 是一种用于不同进程间或一个进程内的不同线程间同步的原语。POSIX信号量不必在内核中维护，可能使用文件系统中的某个文件来标识。

1. 有名信号量操作

#include <semaphore.h>

// 成功返回信号量指针，出错返回SEM_FAILED
sem_t *sem_open(const char *name, int oflag, ...
  /* mode_t mode, unsigned int value */ );

$sem_-open$ 创建一个有名信号量或者打开一个有名信号量。有名信号量既可以用于线程间同步，又可以用于进程间同步。$oflag$ 参数可以是 $0$ 、$O_-CREAT$ 或 $O_-CREAT$ | $O_-EXCL$ 。如果指定了 $O_-CREAT$ ，那么也要指定权限位 $mode$ 和信号量初始值 $value$ 。信号量初始值不能超过 $SEM_-VALUE_-MAX$ ( 这个常值至少为 $32767$ )。

#include <semaphore.h>

/* 成功返回0，出错返回-1 */

int sem_close(sem_t *sem);

int sem_unlink(sem_t *sem);

当进程终止时，内核会对仍然打开着的有名信号量执行关闭操作。关闭一个信号量只是减少其引用计数，并不会删除。如果想要删除一个信号量，需要调用 $sem_-unlink$ 函数。类似于 $unlink$ ，如果在调用 $sem_-unlink$ 时该信号量引用计数不为 $0$ ，依然会进行删除，但是析构会等到引用计数为 $0$ 时才会发生。

#include <semaphore.h>

/* 成功返回0，出错返回-1 */

int sem_wait(sem_t *sem);

int sem_trywait(sem_t *sem);

int sem_post(sem_t *sem);

int sem_getvalue(sem_t *sem, int *valp);

$sem_-wait$ 测试指定信号量的值，如果大于 $0$ ，就将其减 $1$ 并返回；如果不大于 $0$ ，就会阻塞直到该值大于 $0$ ，然后减 $1$ 并返回。如果在阻塞的过程中被中断，$sem_-wait$ 会返回并设置 $EINTR$ 错误。考虑到可能使用同一信号量的其他线程的存在，测试并减 $1$ 这个过程是原子的。$sem_-trywait$ 是 $sem_-wait$ 的非阻塞版本，如果值不大于 $0$ ，它会返回并设置 $EAGAIN$ 错误。
当一个线程使用完信号量后，应该调用 $sem_-post$ 函数将信号值加 $1$ 。$sem_-getvalue$ 会在 $valp$ 中返回信号量的当前值。如果信号量非正值，那么返回值可能是 $0$ ，也可能是一个负数，其绝对值为阻塞在该信号量上的线程数。

Unix网络编程（18）：锁

Mon, 21 Feb 2022 14:36:08 +0800

1. 互斥锁上锁和解锁

#include <pthread.h>

/* 成功返回0，出错返回非负错误码 */

int pthread_mutex_lock(pthread_mutex_t *mptr);

int pthread_mutex_trylock(pthread_mutex_t *mptr);

int pthread_mutex_unlock(pthread_mutex_t *mptr);

POSIX互斥锁被声明为 $pthread_-mutex_-t$ 类型的变量。如果是静态分配的，需要初始化为常值 $PTHREAD_-MUTEX_-INITIALIZER$ ；如果是动态分配的，或者分配在共享内存区中，需要通过 $pthread_-mutex_-init$ 函数初始化。$pthread_-mutex_-lock$ 是阻塞版本的上锁，会一直阻塞直到该互斥锁解锁；$pthread_-mutex_-trylock$ 是非阻塞版本的上锁，如果该互斥锁已经上锁，会返回 $EBUSY$ 错误。

2. 生产者消费者问题

生产者-消费者 ( $producer-consumer$ ) 问题，也称为有界缓冲区 ( $bounded$ $buffer$ ) 问题。一个或多个生产者创建一个个数据条目，这些条目由一个或多个消费者处理。数据条目在生产者和消费者之间使用某种方式的IPC传递。对于使用管道或消息队列进行通信的生产者和消费者，内核会进行隐式同步。然而对于使用共享内存区进行通信的生产者和消费者，需要进行显式同步。我们使用互斥锁进行显式同步。

#include "unpipc.h"

#define MAXNITEMS 1000000
#define MAXNTHREADS 100

int nitems;  // read-only by producer and consumer
struct {
  pthread_mutex_t mutex;
  int buff[MAXNITEMS];
  int nput;
  int nval;
} shared = {
  PTHREAD_MUTEX_INITIALIZER
};

void *produce(void *);
void *consume(void *);

int main(int argc, char **argv) {
  int i, nthreads, count[MAXNTHREADS];
  pthread_t tid_produce[MAXNTHREADS], tid_consume;

  if (argc != 3)
    err_quit("usage: prodcons2 <#items> <#threads>");
  nitems = min(atoi(argv[1]), MAXNITEMS);
  nthreads = min(atoi(argv[2]), MAXNTHREADS);

  Set_concurrency(nthreads);
  // start all the producer threads
  for (i = 0; i < nthreads; i++) {
    count[i] = 0;
    Pthread_create(&tid_produce[i], NULL, produce, &count[i]);
  }

  // wait for all the producer threads
  for (i = 0; i < nthreads; i++) {
    Pthread_join(tid_produce[i], NULL);
    printf("count[%d] = %d\n", i, count[i]);
  }

  // start, then wait for the consumer thread
  Pthread_create(&tid_consume, NULL, consume, NULL);
  Pthread_join(tid_consume, NULL);

  exit(0);
}

$set_-concurrency$ 告知系统我们希望并发运行的线程数。

Unix网络编程（17）：消息队列

Sun, 20 Feb 2022 14:01:51 +0800

消息队列可认为是一个消息链表，有足够写权限的线程可往队列中放置消息，有足够读权限的线程可从队列中取走消息。每个消息都是一个记录，它由发送者赋予一个优先级。与管道和FIFO不同，在某个进程往一个队列写入消息前，并不需要另外某个进程在该队列上等待消息到达。

1. `mq_open`、`mq_close`和`mq_unlink`函数

#include <mqueue.h>

// 成功返回消息队列描述符，出错返回-1
mqd_t mq_open(const char *name, int oflag, ...
  /* mode_t mode, struct aq_attr *attr */ );

// 成功返回0，出错返回-1
int mq_close(mqd_t mqdes);

// 成功返回0，出错返回-1
int mq_unlink(const char *name);

$oflag$ 参数是 $O_-RDONLY$ 、$O_-WRONLY$ 或 $O_-RDWR$ 之一，并且可以按位或 $O_-CREAT$ 、$O_-EXCL$ 或 $O_-NONBLOCK$ 。当实际操作是创建一个新队列时 ( 指定 $O_-CREAT$ 且请求的消息队列不存在 )，需要 $mode$ 和 $attr$ 参数。$mq_-close$ 调用类似于 $close$ 调用，调用之后消息队列不会从系统中删除。当一个进程终止时，它的所有打开着的消息队列会被关闭。如果要从系统中删除一个消息队列，则需要调用 $mq_-unlink$ ，类似于 $unlink$ ，当一个消息队列的打开计数大于 $0$ 时，不会立即删除，而是直到该消息队列真正被关闭时才会删除。POSIX消息队列至少具备随内核的持续性，这意味着即使当前没有进程打开着消息队列，其中的消息也将一直存在，直到被删除。

#include "unpipc.h"

int main(int argc, char **argv) {
  int c, flags;
  mqd_t mqd;

  flags = O_RDWR | O_CREAT;
  while ((c = Getopt(argc, argv, "e")) != -1) {
    switch(c) {
    case 'e':
      flags |= O_EXCL;
      break;
    }
  }
  if (optind != argc - 1)
    err_quit("usage: mqcreate [ -e ] <name>");

  mql = Mq_open(argv[optind], flags, FILE_MODE, NULL);

  Mq_close(mqd);
  exit(0);
}

允许有一个排他选项 $-e$ 创建消息队列。通过 $getopt$ 获取这个选项，$getopt$ 会在 $optind$ 中存放待处理的下一个参数的下标。

Unix网络编程（16）：管道和FIFO

Sat, 19 Feb 2022 14:31:35 +0800

1. 管道

#include <unistd.h>

// 成功返回0，出错返回-1
int pipe(int fd[2]);

该函数返回两个文件描述符 $fd[0]$ 和 $fd[1]$ ，前者用于读，后者用于写。宏 $S_-IFFIFO$ 可用于确定一个描述符是文件、管道还是FIFO，它的唯一参数是 $stat$ 结构的 $st_-mode$ 成员，计算结果或为真 ( 非零值 )，或为假 ( $0$ )。对于管道来说，这个 $stat$ 结构是由 $fstat$ 函数填写的；对于FIFO来说，这个结构是由 $fstat$ 、$lstat$ 或 $stat$ 函数填写的。
管道的典型用途是为两个不同的进程 ( 父进程和子进程 ) 提供进程间通信。首先，由一个进程 ( 父进程 ) 创建一个管道，然后调用 $fork$ 派生一个副本 ( 子进程 )。接着，父进程关闭这个管道的读端 ( $fd[0]$ )，子进程关闭管道的写端 ( $fd[1]$ )，这样就在父子进程间建立了一个单向数据流。我们在Unix shell中输入如下命令时：

who | sort

将会创建一个管道，$who$ 进程通过输出端将数据发送给 $sort$ 进程，$sort$ 进程通过读入端读入 $who$ 进程发送的数据。
管道是单向的，如果需要双向传输数据，我们必须创建两个管道，每个方向一个：

创建管道 $fd1$ 和管道 $fd2$ ，并 $fork$ 一个子进程；
父进程关闭 $fd1[0]$ 和 $fd2[1]$ ；
子进程关闭 $fd1[1]$ 和 $fd2[0]$ 。

#include "unpipc.h"

void client(int, int), server(int, int);

int main(int argc, char **argv) {
  int pipe1[2], pipe2[2];
  pid_t childpid;

  Pipe(pipe1);
  Pipe(pipe2);

  if ((childpid = Fork()) == 0) {  // child
    Close(pipe1[1]);
    Close(pipe2[0]);

    server(pipe1[0], pipe2[1]);
    exit(0);
  }

  // parent
  Close(pipe1[0]);
  Close(pipe2[1]);

  clinet(pipe2[0], pipe1[1]);
  Waitpid(childpid, NULL, 0);  // wait for child to terminate
  exit(0);
}

void client(int readfd, int writefd) {
  size_t len;
  ssize_t n;
  char buff[MAXLINE];

  // read pathname
  Fgets(buff, MAXLINE, stdin);
  len = strlen(buff);  // fgets() guarantees null byte at end
  if (buff[len - 1] == '\n')
    len--;  // delete newline from fgets()

  // write pathname to IPC channel
  Write(writefd, buff, len);

  // read from IPC, write to standard output
  while ((n = Read(readfd, buff, MAXLINE)) > 0)
    Write(STDOUT_FILENO, buff, n);
}

void server(int readfd, int writefd) {
  int fd;
  ssize_t n;
  char buff[MAXLINE + 1];

  // read pathname from IPC channel
  if ((n = Read(readfd, buff, MAXLINE)) == 0)
    err_quit("end-of-file while reading pathname");
  buff[n] = '\0';  // null terminate pathname

  if ((fd = open(buff, O_RDONLY)) < 0) {
    // error: must tell client
    snprintf(buff + n, sizeof(buff) - n, ": can't open, %s\n",
      strerror(errno));
    n = strlen(buff);
    Write(writefd, buff, n);
  } else {
    // open succeeded: copy file to IPC channel
    while ((n = Read(fd, buff, MAXLINE)) > 0)
      Write(writefd, buff, n);
    Close(fd);
  }
}

子进程在往管道写入最终数据后调用 $exit$ 终止，随后变为僵尸进程 ( $zombie$ )：自身终止但父进程仍在运行且未等待该子进程。子进程终止时，内核会给父进程发送一个 $SIGCHILD$ 信号，但是父进程忽略了这个信号。随后父进程调用 $waitpid$ 取得子进程的终止状态。如果父进程没有调用 $waitpid$ 就终止，那么子进程变为孤儿进程，其父进程将变为 $init$ 进程，由 $init$ 进程获取其终止状态。

Unix网络编程补充：套接字选项

Fri, 18 Feb 2022 18:28:56 +0800

1. `getsockopt`和`setsockop`函数

#include <sys/socket.h>

// 成功返回0，出错返回-1
int getsockopt(int sockfd, int level, int optname, void *optval, socklen_t *optlen);

// 成功返回0，出错返回-1
int setsockopt(int sockfd, int level, int optname, const void *optval, socklen_t optlen);

这两个函数仅适用于套接字。$sockfd$ 指向一个打开的套接字描述符，$level$ 指定系统中解释选项的代码或为通用套接字代码，或为某个特定于协议的代码。$optval$ 是一个指向某个变量的指针，$setsockopt$ 从 $optval$ 中获取设置，$getoptval$ 向 $optval$ 中写入设置。$optval$ 的大小由 $optlen$ 指定。套接字选项粗分为两大基本类型：一是启用或禁用某个特性的二元选项 ( 标志选项 )，二是取得并返回我们可以设置或检查的特定值的选项 ( 值选项 )。对于标志选项，$optval$ 是一个整数，$1$ 标识启用，$0$ 表示禁用。

$level$	$optname$	$get$	$set$	说明	标志选项	数据类型
$SOL_-SOCKET$	$SO_-BROADCAST$	$\checkmark$	$\checkmark$	允许发送广播数据报	$\checkmark$	$int$
$SO_-DEBUG$	$\checkmark$	$\checkmark$	开启调试跟踪	$\checkmark$	$int$
$SO_-DONTROUTE$	$\checkmark$	$\checkmark$	绕过外出路由表查询	$\checkmark$	$int$
$SO_-ERROR$	$\checkmark$		获取待处理错误并清除		$int$
$SO_-KEEPALIVE$	$\checkmark$	$\checkmark$	周期性测试连接是否仍存活	$\checkmark$	$int$
$SO_-LINGER$	$\checkmark$	$\checkmark$	若有数据待发送则延迟关闭		$linger\{\}$
$SO_-OOBINLINE$	$\checkmark$	$\checkmark$	让接收到的带外数据在线存留	$\checkmark$	$int$
$SO_-RCVBUF$	$\checkmark$	$\checkmark$	接收缓冲区大小		$int$
$SO_-SNDBUF$	$\checkmark$	$\checkmark$	发送缓冲区大小		$int$
$SO_-RCVLOWAT$	$\checkmark$	$\checkmark$	接收缓冲区低水位标记		$int$
$SO_-SNDLOWAT$	$\checkmark$	$\checkmark$	发送缓冲区低水位标记		$int$
$SO_-RCVTIMEO$	$\checkmark$	$\checkmark$	接收超时		$timeval\{\}$
$SO_-SNDTIMEO$	$\checkmark$	$\checkmark$	发送超时		$timeval\{\}$
$SO_-REUSEADDR$	$\checkmark$	$\checkmark$	允许重用本地地址	$\checkmark$	$int$
$SO_-REUSEPORT$	$\checkmark$	$\checkmark$	允许重用本地端口	$\checkmark$	$int$
$SO_-TYPE$	$\checkmark$		取得套接字类型		$int$
$SO_-USELOOPBACK$	$\checkmark$	$\checkmark$	路由套接字取得所发送数据的副本	$\checkmark$	$int$
$IPPROTO_-IP$	$IP_-HDRINCL$	$\checkmark$	$\checkmark$	随数据包含的`IP`首部	$\checkmark$	$int$
$IP_-OPTIONS$	$\checkmark$	$\checkmark$	`IP`首部选项		见后续
$IP_-RECVDSTADDR$	$\checkmark$	$\checkmark$	返回目的`IP`地址	$\checkmark$	$int$
$IP_-RCVIF$	$\checkmark$	$\checkmark$	返回接收接口索引	$\checkmark$	$int$
$IP_-TOS$	$\checkmark$	$\checkmark$	服务类型和优先权		$int$
$IP_-TTL$	$\checkmark$	$\checkmark$	存活时间		$int$
$IP_-MULTICAST_-IF$	$\checkmark$	$\checkmark$	指定外出接口		$in_-addr\{\}$
$IP_-MULTICAST_-TTL$	$\checkmark$	$\checkmark$	指定外出 $TTL$		$u_-char$
$IP_-MULTICAST_-LOOP$	$\checkmark$	$\checkmark$	指定是否环回		$u_-char$
$IP_-ADD_-MEMBERSHIP$		$\checkmark$	加入多播组		$ip_-mreq\{\}$
$IP_-DROP_-MEMBERSHIP$		$\checkmark$	离开多播组		$ip_-mreq\{\}$
$IP_-BLOCK_-SOURCE$		$\checkmark$	阻塞多播源		$ip_-mreq_-source\{\}$
$IP_-UNBLOCK_-SOURCE$		$\checkmark$	开通多播源		$ip_-mreq_-source\{\}$
$IP_-ADD_-SOURCE_-MEMBERSHIP$		$\checkmark$	加入源特定多播组		$ip_-mreq_-source\{\}$
$IP_-DROP_-SOURCE_-MEMBERSHIP$		$\checkmark$	离开源特定多播组		$ip_-mreq_-source\{\}$
$IPPROTO_-ICMPV6$	$ICMP6_-FILTER$	$\checkmark$	$\checkmark$	指定待传递的`ICMPv6`消息类型		$icmp6_-filter\{\}$
$IPPROTO_-IPV6$	$IPV6_-CHECKSUM$	$\checkmark$	$\checkmark$	用于原始套接字的校验和字段偏移		$int$
$IPV6_-CHECKSUM$	$\checkmark$	$\checkmark$	用于原始套接字的校验和字段偏移		$int$
$IPV6_-DONTFRAG$	$\checkmark$	$\checkmark$	丢弃大的分组而将其分片	$\checkmark$	$int$
$IPV6_-NEXTHOP$	$\checkmark$	$\checkmark$	指定下一跳地址		$sockaddr_-in6\{\}$
$IPV6_-PATHMTU$	$\checkmark$		获取当前路径 $MTU$		$ip6_-mtuinfo\{\}$
$IPV6_-RECVDSTOPTS$	$\checkmark$	$\checkmark$	接收目的地选项	$\checkmark$	$int$
$IPV6_-RECVHOPLIMIT$	$\checkmark$	$\checkmark$	接收单播跳限	$\checkmark$	$int$
$IPV6_-RECVHOPOPTS$	$\checkmark$	$\checkmark$	接收步跳选项	$\checkmark$	$int$
$IPV6_-RECVPATHMTU$	$\checkmark$	$\checkmark$	接收路径 $MTU$	$\checkmark$	$int$
$IPV6_-RECVPKTINFO$	$\checkmark$	$\checkmark$	接收分组信息	$\checkmark$	$int$
$IPV6_-RECVRTHDR$	$\checkmark$	$\checkmark$	接收源路径	$\checkmark$	$int$
$IPV6_-RECVTCLASS$	$\checkmark$	$\checkmark$	接收流通类型	$\checkmark$	$int$
$IPV6_-UNICAST_-HOPS$	$\checkmark$	$\checkmark$	默认单播跳限		$int$
$IPV6_-USE_-MIN_-MTU$	$\checkmark$	$\checkmark$	使用最小 $MTU$	$\checkmark$	$int$
$IPV6_-V6ONLY$	$\checkmark$	$\checkmark$	禁止`v4`兼容	$\checkmark$	$int$
$IPV6_-XXX$	$\checkmark$	$\checkmark$	黏附性辅助数据		见后续
$IPV6_-MULTICAST_-IF$	$\checkmark$	$\checkmark$	指定外出接口		$u_-int$
$IPV6_-MULTICAST_-HOPS$	$\checkmark$	$\checkmark$	指定外出跳限		$int$
$IPV6_-MULTICAST_-LOOP$	$\checkmark$	$\checkmark$	指定是否环回	$\checkmark$	$u_-int$
$IPV6_-JOIN_-GROUP$		$\checkmark$	加入多播组		$ipv6_-mreq\{\}$
$IPV6_-LEAVE_-GROUP$		$\checkmark$	离开多播组		$ipv6_-mreq\{\}$
$IPPROTO_-IP$ 或 $IPPROTO_-IPV6$	$MCAST_-JOIN_-GROUP$		$\checkmark$	加入多播组		$group_-req\{\}$
$MCAST_-LEAVE_-GROUP$		$\checkmark$	离开多播组		$group_-source_-req\{\}$
$MCAST_-BLOCK_-SOURCE$		$\checkmark$	阻塞多播源		$group_-source_-req\{\}$
$MCAST_-UNBLOCK_-SOURCE$		$\checkmark$	开通多播源		$group_-source_-req\{\}$
$MCAST_-JOIN_-SOURCE_-GROUP$		$\checkmark$	加入源特定多播组		$group_-source_-req\{\}$
$MCAST_-LEAVE_-SOURCE_-GROUP$		$\checkmark$	离开源特定多播组		$group_-source_-req\{\}$
$IPPROTO_-TCP$	$TCP_-MAXSEG$	$\checkmark$	$\checkmark$	`TCP`最大分节大小		$int$
$TCP_-NODELAY$	$\checkmark$	$\checkmark$	禁止 $Nagle$ 算法	$\checkmark$	$int$

2. 通用套接字选项

2.1 `SO_DEBUG`

本选项仅由TCP支持。当给一个TCP套接字开启本选项时，内核将为TCP在该套接字发送和接收的所有分组保留详细跟踪信息。这些信息保存在内核的某个环形缓冲区中，并可使用 $trpt$ 程序进行检查。

Unix网络编程（15）：程序设计范式

Fri, 18 Feb 2022 14:37:07 +0800

开发一个Unix服务器程序时，我们有如下类型的进程控制可选：

迭代服务器 ( $iterative$ $server$ ) 程序，在一个主循环内处理所有客户服务。这种类型的适用情形极为有限，因为这样的服务器在完成当前客户的服务之前无法处理后续等待的客户；
并发服务器 ( $concurrent$ $server$ ) 程序，它为每个客户调用 $fork$ 派生一个子进程。传统上大多数Unix服务器程序属于这种类型；
通过 $select$ 处理任意多个客户的服务器；
预先派生子进程 ( $preforking$ ) 程序，它让服务器在启动阶段调用 $fork$ 创建一个子进程池，每个客户请求由当前可用子进程池中的某个闲置子进程处理；
预先创建线程 ( $prethreading$ ) 程序，它让服务器在启动阶段创建一个线程池，每个客户由当前可用线程池中的某个闲置线程处理。

TCP客户程序则有以下范式：

以停-等方式运作的客户程序，进程在被阻塞以等待用户输入期间，看不到诸如对端关闭连接等网络事件，而且批处理效率极低；
调用 $select$ 监听的客户程序，可以得到网络事件通知；
非阻塞式I/O客户程序；
多进程客户程序；
多线程客户程序。

1. `TCP`预先派生子进程服务器程序，`accept`无上锁保护

这种技术的优点在于无须引入父进程执行 $fork$ 的开销就能处理新客户，缺点是父进程必须在服务器启动阶段配置预先派生子进程数量。可选的改进方案是增加一些代码，让父进程监听可用子进程数，一旦降低到某个阈值就派生额外的子进程；同样的，一旦可用子进程数增加到某个阈值就终止一些过剩的子进程。

#include "unp.h"

#define MAXN 16384  // max # bytes client can request

static int nchildren;
static pid_t *pids;

int main(int argc, char **argv) {
  int listenfd, i;
  socklen_t addrlen;
  void sig_int(int);
  pid_t child_make(int, int, int);

  if (argc == 3)
    listenfd = Tcp_listen(NULL. argv[1], &addrlen);
  else if (argc == 4)
    listenfd = Tcp_listen(argv[1], argv[2], &addrlen);
  else
    err_quit("usage: serv02 [ <host> ] <port#> <#children>");
  nchildren = atoi(argv[argc - 1]);
  pids = Calloc(nchildren, sizeof(pid_t));

  for (i = 0; i < nchildren; i++)
    pids[i] = child_make(i, listendfd, addrlen);  // parent returns

  Signal(SIGINT, sig_int);

  for (;;)
    pause();  // everything done by children
}

void sig_int(int signo) {
  int i;

  // terminate all children
  for (i = 0; i < nchildren; i++)
    kill(pids[i], SIGTERM);
  while (wait(NULL) > 0)  // wait for all children
    continue;
  if (errno != ECHILD)
    err_sys("wait error");

  exit(0);
}

pid_t child_make(int i, int listenfd, int addrlen) {
  pid_t pid;
  void child_main(int, int, int);

  if ((pid = Fork()) > 0)
    return pid;  // parent

  child_main(i, listenfd, addrlen);  // never returns
}

void child_main(int i, int listenfd, int addrlen) {
  int connfd;
  void web_child(int);
  socklen_t clilen;
  struct sockaddr *cliaddr;

  cliaddr = Malloc(addrlen);

  printf("child %ld starting\n", (long) getpid());
  for (;;) {
    clilen = addrlen;
    connfd = Accept(listenfd, cliaddr, &clilen);
    web_child(connfd);  // process the request
    Close(connfd);
  }
}

void web_child(int sockfd) {
  int ntowrite;
  ssize_t nread;
  char line[MAXLINE], result[MAXN];

  for (;;) {
    if ((nread = Realine(sockfd, line, MAXLINE)) == 0)
      return;  // connection closed by other end

    // line from client specifies #bytes to write back
    ntowrite = atol(line);
    if ((ntowrite <= 0) || (ntowrite > MAXN))
      err_quit("client request for %d bytes", ntowrite);

    Writen(sockfd, result, ntowrite);
  }
}

父进程在派生任何子进程之前创建监听套接字，从而每次 $fork$ 时，所有描述符也被复制。服务器进程在程序启动阶段派生 $N$ 个子进程，它们各自调用 $accept$ 并处于休眠状态。当客户连接到达时，所有子进程均被唤醒，因为它们使用同一个监听描述符，但是只有最先运行的子进程会获得连接，其余子进程会重新休眠。这就是惊群 ( $thundering$ $herd$ ) 问题，尽管只有一个子进程获得连接，所有的子进程却都被唤醒了，这样会导致性能受损。
与这个例子相关的另一种现象是 $select$ 冲突。如果我们通过 $select$ 来 $accept$ 新客户，那么内核会唤醒所有在阻塞在 $select$ 并且等待同一个监听套接字的进程，从而产生冲突。从以上问题，我们可以得出：如果有多个进程阻塞在引用同一个实体的描述符上，最好直接阻塞在 $accept$ 等函数中，而不是 $select$ 上。

Unix网络编程（14）：线程

Thu, 17 Feb 2022 14:28:16 +0800

在传统的Unix模型中，当一个进程需要另一个实体来完成某事时，它就 $fork$ 一个子进程并让子进程去处理。尽管这种范式多年来一直应用得挺好，但是 $fork$ 调用却存在一些问题：

$fork$ 是重量级调用。$fork$ 调用要把父进程的内存映射到子进程，并在子进程中复制所有描述符等。当今的实现使用写时复制 ( $copy-on-write$ ) 技术，只有子进程需要时才会复制数据。然而，即使存在这样的优化，$fork$ 依然是重量级调用；
$fork$ 返回之后父子进程之间的信息传递需要进程间通信机制。

线程有助于解决这两个问题，它的创建可能比进程快 $10 \sim 100$ 倍，而且同一进程内的线程共享相同的全局内存。然而，线程的引入也会带来同步 ( $synchronization$ ) 问题。同一进程内的所有线程除了共享全局变量之外还共享：

进程指令；
大多数数据；
打开的文件 ( 描述符 )；
信号处理函数和信号处置；
当前工作目录；
用户ID和组ID。

每个线程也有各自的：

线程ID ( TID )；
寄存器集合，包括程序计数器和栈指针；
栈 ( 存放局部变量和返回地址 )；
$errno$ ；
信号掩码；
优先级。

1. 创建和终止

1.1 `pthread_create`函数

#include <pthread.h>

// 成功返回0，出错返回非负错误码
int pthread_create(pthread_t *tid, const pthread_attr_t *attr,
  void *(*func)(void *), void *arg);

当一个程序由 $exec$ 启动时，称为初始线程 ( $initial$ $thread$ ) 或主线程 ( $main$ $thread$ ) 的单个线程就创建了，其余线程则由 $pthread_-create$ 函数创建。一个进程内每个线程都由线程ID标识，数据类型为 $pthread_-t$ 。如果新线程成功创建，ID会通过 $tid$ 返回。每个线程都有属性：优先级、初始栈大小、是否应该成为守护线程等，可以通过 $attr$ 参数指定。通常情况下我们采取默认配置，这时会把 $attr$ 设置为 $NULL$ 。最后两个参数是线程执行的函数以及参数，线程通过调用这个函数开始执行，然后显式终止 ( $pthread_-exit$ ) 或者隐式终止 ( 函数返回 ) 。如果我们需要传递多个参数，需要把它们打包成一个结构，通过结构指针传递。

Unix网络编程（13）：信号驱动式I/O

Wed, 16 Feb 2022 16:55:21 +0800

信号驱动式I/O是指进程预先告知内核，使得当某个描述符上发生某事时，内核使用信号通知相关进程。

1. 套接字的信号驱动式`I/O`

针对一个套接字使用信号驱动式I/O ( $SIGIO$ ) 要求进程执行以下 $3$ 个步骤：

创建 $SIGIO$ 信号的信号处理函数；
设置该套接字的属主；
开启该套接字的信号驱动式I/O，通常通过使用 $fcntl$ 的 $F_-SETFL$ 命令打开 $O_-ASYNC$ 标志。

1.1 对于`UDP`套接字的`SIGIO`信号

在UDP上使用信号驱动式I/O是简单的。$SIGIO$ 信号在发生以下事件时产生：

数据报到达套接字；
套接字上发生异步错误。

因此当捕获对于某个UDP套接字的 $SIGIO$ 信号时，我们调用 $recvfrom$ 或者读入到达的数据报，或者获取发生的异步错误。

1.2 对于`TCP`套接字的`SIGIO`信号

信号驱动式I/O对于TCP套接字近乎无用，因为该信号产生得过于频繁，并且信号出现并没有告诉我们发生了什么事。下列条件均导致TCP套接字产生 $SIGIO$ 信号：

监听套接字上某个连接请求已经完成；
某个断连的请求已经发起；
某个断连的请求已经完成；
某个连接已经半关闭；
数据到达套接字；
数据已经从套接字发送走 ( 即输出缓冲区有空闲空间 )；
发生异步错误。

我们应该只考虑对监听套接字使用 $SIGIO$ ，因为监听套接字产生 $SIGIO$ 的唯一条件是某个新连接的完成。

2. 使用`SIGIO`的`UDP`回射服务器程序

使用 $SIGIO$ 的UDP回射程序可以设计为这种形式：当一个数据报到达时，$SIGIO$ 处理函数读入数据报，同时记录到达时刻，然后将它置于进程内的另一个队列中，主服务器循环从队列中取出数据并处理。相比起不使用 $SIGIO$ 而是简单使用一个服务器循环处理的程序，这种形式可以精确的获知数据报到达时间戳。

#include "unp.h"

static int sockfd;

#define QSIZE 8 // size of input queue
#define MAXDG 4096

typedef struct {
  void *dg_data;  // ptr to actual datagram
  size_t dg_len;  // length of datagram
  struct sockaddr *dg_sa;  // ptr to sockaddr{} w/client's address
  socklen_t dg_salen;  // length of sockaddr
} DG;

static DG dg[QSIZE];  // queue of datagrams to process
static long cntread[QSIZE + 1];  // diagnostic counter

static int iget;  // next one for main loop to process
static int iput;  // next one for signal handler to read into
static int nqueue;  // # on queue for main loop to process
static socklen_t clilen;  // max length of sockaddr{}

static void sig_io(int);
static void sig_hup(int);

void dg_echo(int sockfd_arg, struct sockaddr *pcliaddr, socklen_t clilen_arg) {
  int i;
  const int on = 1;
  sigset_t zeromask, newmask, oldmask;

  sockfd = sockfd_arg;
  clilen = clilen_arg;

  for (i = 0; i < QSIZE; i++) {  // init queue of buffers
    dg[i].dg_data = Malloc(MAXDG);
    dg[i].dg_sa = Malloc(clilen);
    dg[i].dg_salen = clilen;
  }
  iget = iput = nqueue = 0;

  Signal(SIGHUP, sig_hup);
  Signal(SIGIO, sig_io);
  Fcntl(sockfd, F_SETOWN, getpid());
  Ioctl(sockfd, FIOASYNC, &on);
  Ioctl(sockfd, FIONBIO, &on);

  Sigemptyset(&zeromask);  // init three signal sets
  Sigemptyset(&oldmask);
  Sigemptyset(&newmask);
  Sigaddset(&newmask, SIGIO);  // signal we want to block

  Sigprocmask(SIG_BLOCK, &newmask, &oldmask);
  for (;;) {
    while (nqueue == 0)
      sigsuspend(&zeromask);  // wait for datagram to process
    // unblock SIGIO
    Sigprocmask(SIG_SETMASK, &oldmask, NULL);
    Sendto(sockfd, dg[iget].dg_data, dg[iget].dg_len, 0,
      dg[iget].dg_sa, dg[iget].dg_salen);
    if (++iget >= QSIZE)
      iget = 0;
    // block SIGIO
    Sigprocmask(SIG_BLOCK, &newmask, &oldmask);
    nqueue--;
  }
}

$SIGIO$ 信号处理函数把数据报放入一个 $DG$ 数组，我们把它作为环形缓冲区处理；
$iget$ 指向下一个待处理的数组元素下标，$iput$ 指向下一个可存放数据的数组下标，$nqueue$ 是数组中待处理的数据报总数；
初始化三个信号集：$zeromask$ ( 从不改变 )、$oldmask$ ( 记录阻塞 $SIGIO$ 时原来的掩码 ) 和 $newmask$ ；
首次调用 $sigprocmask$ 会把进程的当前信号掩码保存到 $oldmask$ 中，然后把 $newmask$ 逻辑或到当前信号掩码，这将阻塞 $SIGIO$ 并返回当前信号掩码；
当 $nqueue$ 为 $0$ 时，代表没有数据到达，调用 $sigsuspend$ 。该函数会先内部保存当前信号掩码，再设置当前信号掩码为它的参数 ( $zeromask$ )，该函数总是返回 $EINTR$ 错误。因为 $zeromask$ 是一个空信号集，所以所有信号都可以被捕获，$sigsuspend$ 捕获一个信号，并且等待该信号的处理函数返回后才会返回。在返回之前，$sigsuspend$ 会恢复当前信号掩码，在本例中是 $newmask$ ；
调用 $sigprocmask$ 解除 $SIGIO$ 的阻塞状态，然后调用 $sendto$ 发送回复，递增 $iget$ ，表示该数据报已经被处理；
再次调用 $sigprocmask$ ，重新阻塞 $SIGIO$ ，最后递减 $nqueue$ 。

在上述函数中，我们在一个循环内不断地阻塞和解阻塞 $SIGIO$ ，是为了保证安全地修改和判断 $nqueue$ ，因为相应的信号处理函数也会修改 $nqueue$ 。另一种方法是让 $SIGIO$ 一直阻塞，但是这样做降低了信号处理函数的及时性，因为直到 $sigsuspend$ 被调用时信号处理函数才会被调用。

Unix网络编程（12）：带外数据

Tue, 15 Feb 2022 17:50:04 +0800

许多传输层有带外数据 ( $out-of-band$ $data$ ) 的概念，有时也被称为经加速数据 ( $expedited$ $data$ )。当一个连接的某端发生了重要的事情，而且该端希望迅速告知对端，这意味着这些数据应该在已经排队等待发送的任何普通数据之前发送。带外数据并不要求在客户和服务器之间再创建一个连接，而是使用现有的连接。不幸的是，几乎每个传输层都有各自不同的带外数据的实现。UDP是一个极端的例子，没有带外数据。

1. `TCP`带外数据

TCP并没有真正的带外数据，不过提供了紧急模式 ( $urgent$ $mode$ )。以下为TCP发送缓冲区。

进程以 $MSG_-OOB$ 标志发送一个带外数据：

send(fd, "a", 1, MSG_OOB);

TCP将这个数据放置在发送缓冲区的下一个可用位置，并把该连接的TCP紧急指针设置为下一个可用位置。

TCP紧急指针对应一个TCP序列号，它是使用 $MSG_-OOB$ 标志写出的最后一个数据字节 ( 即带外数据字节 ) 对应的序列号加 $1$ 。发送端TCP将为待发送的下一个分节在TCP首部设置URG标志，并把TCP紧急偏移 ( $urgent$ $offset$ ) 字段设置为紧急指针指向的字节，这个分节可能包含也可能不含之前发送的带外数据。$16$ 位的TCP序列号加上 $16$ 位的紧急偏移字段即可得到 $32$ 位的紧急指针。TCP紧急模式的一个重要特点是TCP首部指出发送端已经进入紧急模式 ( 设置URG标志 )，但是紧急指针指向的实际数据字节却不一定发送。
从接收端的角度来看，发生了以下事件：

收到URG分节，接收端检查紧急指针，确定它是否指向带外数据，也就是判断本分节是不是首个到达的紧急模式分节。发送端TCP往往发送多个URG分节并且其紧急指针都会指向同一个数据字节的分节，只有第一个到达的分节会通知接收进程有新的带外数据到达；
当有新的紧急指针到达时，不论由紧急指针指向的实际数据字节是否已经到达，接收进程会收到通知。内核给接收套接字的进程发送 $SIGURG$ 信号，前提是接收进程 ( 或其他进程 ) 曾调用 $fcntl$ 或 $ioctl$ 为这个套接字建立了属主，而且该属主今后层已经为 $SIGURG$ 信号建立了信号处理函数。其次，如果接收进程阻塞在 $select$ 调用中，$select$ 调用就立即返回；
当由紧急指针指向的实际数据字节到达接收端TCP时，该数据字节可能被拉出带外，也可能留在带内。$SO_-OOBINLINE$ 套接字选项默认是禁止的，对于这样的套接字，该数据字节并不立即放入接收缓冲区，而是放入该连接的一个独立的单字节带外缓冲区。接收进程从这个单字节缓冲区中读入数据的唯一方法是指定 $MSG_-OOB$ 标志调用 $recv$ 、$recvfrom$ 或 $recvmsg$ 。如果新的带外字节在就旧的带外字节被读取之前到达，旧的带外字节会被丢弃。如果开启了 $SO_-OOBINLINE$ ，接收进程不能通过 $MSG_-OOB$ 标志读入带外数据，而是通过检查连接的带外标记获悉何时访问到这个字节。

这个过程可能会发送以下错误：

Unix网络编程（11）：路由套接字

Mon, 14 Feb 2022 19:31:39 +0800

注：以下内容可能不适用于Linux系统

内核中的Unix路由表传统上一直使用 $ioctl$ 访问，但是 $ioctl$ 不能输出整个路由表，而诸如 $netstat$ 等程序通过读取内核的内存获取路由表内容。诸如 $gated$ 等路由守护进程需要监视由内核收取的ICMP重定向消息，它们通常创建一个原始ICMP套接字，再在这个套接字上监听所有收到的ICMP消息。在路由域中支持的唯一一种套接字是原始套接字。路由套接字上支持 $3$ 种类型的操作：

进程可以通过写出到路由套接字而往内核发送消息。路径的增加和删除采用这种操作实现；
进程可以通过从路由套接字读入而从内核接收消息。内核采用这种操作通知进程已收到并处理一个ICMP重定向消息，或者请求外部路由进程解析一个路径；
进程可以使用 $sysctl$ 函数输出路由表或者列出所有已配置的接口。

前两种操作可以复合使用，需要超级用户权限，最后一种任何进程都可以执行。

1. 数据链路套接字地址结构

#include <net/if_dl.h>

struct sockaddr_dl {
  uint8_t sdl_len;
  sa_family_t sdl_family;  // AF_LINK
  uint16_t sdl_index;  // 大于0的系统分配的索引
  uint8_t sdl_type;  // IFT_ETHER等在<net/if_types.h>中定义的常值
  uint8_t sdl_nlen;  // 名字长度，从sdl_data[0]开始
  uint8_t sdl_alen;  // 链路层地址长度
  uint8_t sdl_slen;  // 链路层选择器长度
  char sdl_data[12];  // 最小工作区域，可以扩大，包含i/f名称和链路层地址
};

#define LLADDR(s)  ((caddr_t) ((s)->sdl_data + (s)->sdl_nlen))

每个接口都有一个唯一的索引。$sdl_-data$ 成员含有名字和链路层地址，名字从 $sdl_-data[0]$ 开始，并且不以空字符结尾。链路层地址从 $sdl_-data[sdl_-nlen]$ 开始，$LLADDR$ 宏返回指向链路层地址的指针。

2. 套接字读写

创建一个路由套接字以后，进程可以通过写到该套接字向内核发送命令，通过从套接字读来从内核接收信息。路由套接字共有 $12$ 个路由消息，定义在 <$net/route.h$> 头文件中。

消息类型	写到内核	从内核读	说明	结构类型
$RTM_-ADD$	$\checkmark$	$\checkmark$	增加路径	$rt_-msghdr$
$RTM_-CHANGE$	$\checkmark$	$\checkmark$	改动网关、测度或标志	$rt_-msghdr$
$RTM_-DELADDR$		$\checkmark$	地址从接口中删除	$ifa_-msghdr$
$RTM_-DELETE$	$\checkmark$	$\checkmark$	删除路径	$rt_-msghdr$
$RTM_-DELMADDR$		$\checkmark$	多播地址从接口中删除	$ifma_-msghdr$
$RTM_-GET$	$\checkmark$	$\checkmark$	报告测度及其他路径信息	$rt_-msghdr$
$RTM_-IFINFO$		$\checkmark$	接口可用、不可用等	$if_-msghdr$
$RTM_-LOCK$	$\checkmark$	$\checkmark$	锁住给定的测度	$rt_-msghdr$
$RTM_-LOSING$		$\checkmark$	内核怀疑路径即将失效	$rt_-msghdr$
$RTM_-MISS$		$\checkmark$	地址查找失败	$rt_-msghdr$
$RTM_-NEWADDR$		$\checkmark$	地址被添加至接口	$ifa_-msghdr$
$RTM_-NEWMADDR$		$\checkmark$	多播地址被添加至接口	$ifa_-msghdr$
$RTM_-REDIRECT$		$\checkmark$	内核被告知使用另外的路径	$rt_-msghdr$
$RTM_-RESOLVE$		$\checkmark$	请求把目的地址解析成链路层地址	$rt_-msghdr$

通过路由套接字交换的结构有 $5$ 个类型。

Unix网络编程（10）：ioctl

Mon, 14 Feb 2022 15:10:53 +0800

$ioctl$ 函数传统上一直作为那些不适合归入其他精细定义类别的特性的系统接口。POSIX致力于摆脱处于标准化过程的特定功能的 $ioctl$ 接口，办法是为它们创造一些特殊的函数以取代 $ioctl$ 请求，办法是为它们创造一些特殊的函数以取代 $ioctl$ 请求。网络层程序经常在程序启动执行后使用 $ioctl$ 获取所在主机全部网络接口的信息，包括：接口地址、是否支持广播、是否支持多播等。

1. `ioctl`函数

#include <unistd.h>

// 成功返回 $0$ ，出错返回-1
int ioctl(int fd, int request, ... /* void *arg */);

第三个参数是一个指针，类型依赖于 $request$ 参数。我们可以把和网络相关的请求分为 $6$ 类：

类别	$request$	说明	数据类型
套接字	$SIOCATMARK$	是否位于带外标记	$int$
$SIOCSPGRP$	设置套接字的进程`ID`或进程组`ID`	$int$
$SIOCGPGRP$	获取套接字的进程`ID`或进程组`ID`	$int$
文件	$FIONBIO$	设置/清除非阻塞式`I/O`标志	$int$
$FIOASYNC$	设置/清除信号驱动异步`I/O`标志	$int$
$FIONREAD$	获取接收缓冲区的字节数	$int$
$FIOSETOWN$	设置文件的进程`ID`或进程组`ID`	$int$
$FIOGETOWN$	获取文件的进程`ID`或进程组`ID`	$int$
接口	$SIOCGIFCONF$	获取所有接口的列表	$struct$ $ifconf$
$SIOCSIFADDR$	设置接口地址	$struct$ $ifreq$
$SIOCGIFADDR$	获取接口地址	$struct$ $ifreq$
$SIOCGIFADDR$	获取接口地址	$struct$ $ifreq$
$SIOCSIFFLAGS$	设置接口标志	$struct$ $ifreq$
$SIOCGIFFLAGS$	获取接口标志	$struct$ $ifreq$
$SIOCSIFDSTADDR$	设置点到点地址	$struct$ $ifreq$
$SIOCGIFDSTADDR$	获取点到点标志	$struct$ $ifreq$
$SIOCGIFBRDADDR$	获取广播地址	$struct$ $ifreq$
$SIOCSIFBRDADDR$	设置广播地址	$struct$ $ifreq$
$SIOCGIFNETMASK$	获取子网掩码	$struct$ $ifreq$
$SIOCSIFNETMASK$	设置子网掩码	$struct$ $ifreq$
$SIOCGIFMETRIC$	获取接口的测度	$struct$ $ifreq$
$SIOCSIFMETRIC$	设置接口的测度	$struct$ $ifreq$
$SIOCGIFMTU$	获取接口 $MTU$	$struct$ $ifreq$
`ARP`	$SIOCSARP$	创建/修改`ARP`表项	$struct$ $arpreq$
$SIOCGARP$	获取`ARP`表项	$struct$ $arpreq$
$SIOCDARP$	删除`ARP`表项	$struct$ $arpreq$
路由	$SIOCADDRT$	增加路径	$struct$ $rtentry$
$SIOCDELRT$	删除路径	$struct$ $rtentry$
流	$I_-xxx$	以后说明

2. 套接字操作

$SIOCATMARK$ ：如果本套接字的读指针当前位于带外标记，那就通过第三个参数指向的整数值返回一个非 $0$ 值；否则返回一个 $0$ 值；
$SIOCGPGRP$ ：通过第三个参数指向的整数返回本套接字的进程ID或进程组ID，该ID指定针对本套接字的 $SIGIO$ 或 $SIGURG$ 信号的接收过程。本请求和 $fcntl$ 的 $F_-GETOWN$ 命令等效；
$SIOCSPGRP$ ：把本套接字的进程ID或进程组ID设置成由第三个参数指向的整数，该ID指定针对本套接字的 $SIGIO$ 或 $SIGURG$ 信号的接收过程。本请求和 $fcntl$ 的 $F_-SETOWN$ 命令等效。

3. 文件操作

$FIONBIO$ ：根据 $ioctl$ 的第三个参数指向一个 $0$ 值或非 $0$ 值，可清除或设置本套接字的非阻塞式I/O标志。本请求和 $O_-NONBLOCK$ 文件状态标志等效，而可以通过 $fcntl$ 的 $F_-SETFK$ 命令清除或设置该标志；
$FIOASYNC$ ：根据 $ioctl$ 的第三个参数指向一个 $0$ 值或非 $0$ 值，可清除或设置针对本套接字的信号驱动异步I/O标志，它决定是否收取针对本套接字的异步I/O信号 ( $SIGIO$ )。本请求和 $O_-ASYNC$ 文件状态标志等效，可以通过 $fcntl$ 清除或设置该标志；
$FIONREAD$ ：通过由 $ioctl$ 的第三个参数指向的整数返回当前在本套接字接收缓冲区中的字节数。本特性同样适用于文件、管道和终端；
$FIOSETOWN$ / $FIOGETOWN$ ：对于套接字和 $SIOCGPGRP$ 等效。

4. 接口配置

处理网络接口的许多程序沿用的初始步骤之一就是从内核获取配置在系统中的所有接口。本任务由 $SIOCGIFCONF$ 请求完成，使用 $ifconf$ 结构，$ifconf$ 又使用 $ifreq$ 结构。

Unix网络编程（9）：非阻塞式I/O

Sat, 12 Feb 2022 17:12:54 +0800

套接字的默认状态是阻塞的，这就意味着当发出一个不能立即完成的套接字调用时，其进程将被置于休眠状态，直到相应操作完成。可能阻塞套接字的调用分为以下四类：

输入：$read$ 、$readv$ 、$recv$ 、$recvfrom$ 和 $recvmsg$ 共 $5$ 个函数。如果对阻塞式套接字调用，而且套接字接收缓冲区中没有数据可读，进程将休眠。而对于非阻塞式套接字，如果输入操作不能被满足，调用将返回 $EWOULDBLOCK$ 错误；
输出：$write$ 、$writev$ 、$send$ 、$sendto$ 和 $sendmsg$ 共 $5$ 个函数。如果对阻塞式套接字调用，而且套接字发送缓冲区中没有空间，进程将休眠。对于非阻塞的TCP套接字，如果发送缓冲区中没有空间，输出函数调用将立即返回 $EWOULDBLOCK$ 错误；
接受外来连接，即 $accept$ 函数。如果对一个非阻塞套接字调用 $accept$ 函数，而且无新连接到达，将会立即返回 $EWOULDBLOCK$ 错误；
发起外出连接，即用于TCP的 $connect$ 函数。如果对一个非阻塞套接字调用 $connect$ ，而且连接不能立即建立，那么会立即返回 $EINPROGRESS$ 错误。

1. 非阻塞读和写

#include "unp.h"
#include <time.h>

char *gf_time(void);

void str_cli(FILE *fp, int sockfd) {
  int maxfdp1, val, stdineof;
  ssize_t n , nwritten;
  fd_set rset, wset;
  char to[MAXLINE], fr[MAXLINE];
  char *toiptr, *tooptr, *friptr, *froptr;

  val = Fcntl(sockfd, F_GETFL, 0);
  Fcntl(sockfd, F_SETFL, val | O_NONBLOCK);

  val = Fcntl(STDIN_FILENO, F_GETFL, 0);
  Fcntl(STDIN_FILENO, F_SETFL, val | O_NONBLOCK);

  val = Fcntl(STDOUT_FILENO, F_GETFL, 0);
  Fcntl(STDOUT_FILENO, F_SETFL, val | O_NONBLOCK);

  toiptr = tooptr = to;
  friptr = froptr = fr;
  stdineof = 0;

  maxfdp1 = max(max(STDIN_FILENO, STDOUT_FILENO), sockfd) + 1;
  for (;;) {
    FD_ZERO(&rset);
    FD_ZERO(&wset);
    if (stdineof == 0 && toiptr < &to[MAXLINE])
      FD_SET(STDIN_FILENO, &rset);  // read from stdin
    if (friptr < &fr[MAXLINE])
      FD_SET(sockfd, &rset);  // read from socket
    if (tooptr != toiptr)
      FD_SET(STDOUT_FILENO, &wset);  // write to socket
    if (froptr != friptr)
      FD_SET(STDOUT_FILENO, &wset);  // write to stdout

    Select(maxfdp1, &set, &wset, NULL, NULL);

    if (FD_ISSET(STDIN_FILENO, &rset)) {
      if ((n = read(STDIN_FILENO, toiptr, &to[MAXLINE] - toiptr)) < 0) {
        if (errno != EWOULDBLOCK)
          err_sys("read error on stdin");
      } else if (n == 0) {
        fprintf(stderr, "%s: EOF on stdin\n", gf_time());
        stdineof = 1;  // all done withn stdin
        if (tooptr == toiptr)
          Shutdown(sockfd, SHUT_WR);  // send FIN
      } else {
        fprintf(stderr, "%s: read %d bytes from stdin\n", gf_time(), n);
        toiptr += n;
        FD_SET(sockfd, &wset);  // try and write to socket below
      }
    }

    if (FD_ISSET(sockfd, &rset)) {
      if ((n = reada(sockfd, friptr, &fr[MAXLINE] - friptr)) < 0) {
        if (errno != EWOULDBLOCK)
          err_sys("read error on socket");
      } else if (n == 0) {
        fprintf(stderr, "%s: EOF on socket\n", gf_time());
        if (stdineof)
          return;  // normal termination
        else
          err_quit("str_cli: server terminated prematurely");
      } else {
        fprintf(stderr, "%s: read %d bytes from socket\n", gf_time(), n);
        friptr += n;
        FD_SET(STDOUT_FILENO, &wset);  // try and write below
      }
    }

    if (FD_ISSET(STDOUT_FILENO, &wset) && ((n = friptr - froptr) > 0)) {
      if ((nwritten = write(STDOUT_FILENO, froptr, n)) < 0) {
        if (errno != EWOULDBLOCK)
          err_sys("write error to stdout");
      } else {
        fprintf(stderr, "%s: wrote %d bytes to stdout\n", gf_time(), nwritten);
        froptr += nwritten;
        if (froptr == friptr)
          froptr = friptr = fr;  // back to beginning of buffer
      }
    }

    if (FD_ISSET(sockfd, &wset) && ((n = toiptr - tooptr) > 0)) {
      if ((nwritten = write(sockfd, tooptr, n)) < 0) {
        if (errno != EWOULDBLOCK)
          err_sys("write error to socket");
      } else {
        fprintf(stderr, "%s: wrote %d bytes to socket\n", gf_time(), nwritten);
        tooptr += nwritten;
        if (tooptr == toiptr) {
          toiptr = tooptr = to;  // back to beginning of buffer
          if (stdineof)
            Shutdown(sockfd, SHUT_WR);  // send FIN
        }
      }
    }
  }
}

char *gf_time() {
  struct timeval tv;
  static char str[30];
  char *ptr;

  if (gettimeofday(&tv, NULL) < 0)
    err_sys("gettimeofday error");

  ptr = ctime(&tv.tv_sec);
  strcpy(str, &ptr[11]);
  // Fri Sep 13 00:00:00 1986\n\0
  // 0123456789012345678901234 5
  snprintf(str + 8, sizeof(str) - 8, ".%06ld", tv.tv_usec);

  return str;
}

维护两个缓冲区：$to$ 容纳从标准输入到服务器的数据，$fr$ 容纳从服务器到标准输出的数据。其中 $toiptr$ 指针指向从标准输入读入的数据存放的起始字节，$tooptr$ 指向下一个应当向套接字写入的字节；$friptr$ 指向从从套接字读入的数据存放的起始字节，$ftoptr$ 指向下一个应当向标准输出写入的字节。一旦 $tooptr$ 移动到 $toiptr$ 这两个指针就一起恢复到缓冲区开始，$froptr$ 和 $friptr$ 同理；
$fcntl$ 把 $3$ 个描述符都设置为非阻塞；
如果发生 $EWOULDBLOCK$ 错误，就忽略。通常情况下这种情况不会发生，因为 $select$ 已经告诉我们该描述符可读；

可以发现使用非阻塞I/O比较复杂，需要进行缓冲区管理，但是确可以让代码在批量模式下运行速度提高。然而考虑到结果代码的复杂性，像上述方式那样使用非阻塞式I/O是不值得的。我们发现，每当需要使用非阻塞式I/O时，更简单的办法通常是把应用程序任务划分到多个进程或多个线程。

Unix网络编程（8）：Unix域协议

Sat, 12 Feb 2022 14:58:42 +0800

Unix域协议并不是一个实际的协议族，而是在单个主机上执行客户/服务器通信的一种方法，所用API就是在不同主机上执行客户/服务器通信所用的API，因此，Unix域协议可视为IPC方法之一。Unix域提供两类套接字：字节流套接字 ( 类似TCP ) 和数据报套接字 ( 类似UDP )。

1. 套接字地址结构

#include <sys/un.h>

struct sockaddr_un {
  sa_family_t sun_family;  // AF_LOCAL
  char sun_path[104];  // null-terminated pathname
};

存放在 $sun_-path$ 数组中的路径名必须以空字符结尾。实现提供一个 $SUN_-LEN$ 宏以一个指向 $sockaddr_-un$ 结构的指针为参数并返回该结构的长度，包括路径名中的非空字节数。未指定地址通过空字符串作为路径名指示，等价于IPv4的 $INADDR_-ANY$ 常值或IPv6的 $IN6ADDR_-ANY_-INIT$ 常值。

#include "unp.h"

int main(int argc, char **argv) {
  int sockfd;
  socklen_t len;
  struct sockaddr_un addr1, addr2;

  if (argc != 2)
    err_quit("usage: unixbind <pathname>");

  sockfd = Socket(AF_LOCAL, SOCK_STREAM, 0);
  unlink(argv[1]);
  bzero(&addr1, sizeof(addr1));
  addr1.sun_family = AF_LOCAL;
  strncpy(addr1.sun_path, argv[1], sizeof(addr1.sun_path) - 1);
  Bind(sockfd, (struct sockaddr *) &addr2, SUN_LEN(&addr1));

  len = sizeof(addr2);
  Getsockname(sockfd, (struct sockaddr *) &addr2, &len);
  printf("bound name = %s, returned len = %d\n", addr2.sun_path, len);

  exit(0);
}

我们调用 $bind$ 捆绑到套接字上的路径名就是命令行参数，如果文件系统中已存在该路径名，$bind$ 将会失败，所以我们先调用 $unlink$ 删除这个路径名，防止它已存在。如果不存在，$unlink$ 会返回一个可以忽略的错误。

Unix网络编程（7）：高级I/O函数

Fri, 11 Feb 2022 16:00:04 +0800

1. 套接字超时

在涉及套接字的I/O操作上设置超时的办法有以下三种：

调用 $alarm$ ，它在指定超时期满时产生 $SIGALRM$ 信号。这个办法涉及信号处理，而信号处理在不同的实现上存储差异，而且可能干扰进程中现有的 $alarm$ 调用；
在 $select$ 中阻塞等待I/O，以此代替直接阻塞在 $read$ 或 $write$ 调用上；
使用较新的 $SO_-RCVTIMEO$ 和 $SO_-SNDTIMEO$ 套接字选项。这个办法的问题在于并非所有实现都支持这两个套接字选项。

以上三种技术都适用于输入和输出操作，不过我们依然期待可用于 $connect$ 技术，因为TCP内置的 $connect$ 超时时间相当长 ( 典型为 $75$ 秒 )。$select$ 可用来在 $connect$ 上设置超时的先决条件是相应套接字处于非阻塞模式，而那两个套接字选项对 $connect$ 并不适用。还要注意，前两个技术适用于任何描述符，而最后一个只适用于套接字描述符。

#include "unp.h"

static void connect_alarm(int);

int connect_timeo(int sockfd, const struct sockaddr *saptr, socklen_t salen, int nsec) {
  Sigfunc *sigfunc;
  int n;

  sigfunc = Signal(SIGALRM, connect_alarm);
  if (alarm(nsec) != 0)
    err_msg("connect_timeo: alarm was already set");

  if ((n = connect(sockfd, saptr, salen)) < 0) {
    close(sockfd);
    if (errno == EINTR) errno = ETIMEDOUT;
  }
  alarm(0);  // turn off the alarm
  Signal(SIGALRM, sigfunc)  // restore previous signal handler

  return n;
}

static void connect_alarm(int signo) {
  return;  // just interrupt the connect()
}

上述代码使用第一种方法，通过 $alarm$ 设置秒数，再通过信号处理函数中断 $connect$ 调用，同时关闭套接字。自定义的 $Signal$ 函数也会阻塞 $SA_-RESTART$ 信号。要注意，如果指定 $nsec$ 为一个大于 $75$ 的值，那么函数仍然会在 $75$ 秒时超时并返回。还要注意，虽然通过这种方式实现简单，但是在多线程程序中，正确使用信号是很困难的，所以建议只在未线程化或单线程程序中适用该技术。

Unix网络编程（6）：守护进程

Wed, 09 Feb 2022 16:20:07 +0800

守护进程 ( $daemon$ ) 是在后台运行且不与任何控制终端关联的进程。Unix系统通常有很多守护进程在后台运行，执行不同的管理任务。守护进程没有控制终端通常源于它们由系统初始化脚本启动，然而守护进程也可能从某个终端由用户在shell提示符下输入命令行启动，这样的守护进程必须亲自脱离与控制终端的关联。

1. `syslogd`守护进程

Unix系统中的 $syslogd$ 守护进程通常由某个系统初始化脚本启动，而且在系统工作期间一直运行。Linux系统的不同发行版会使用各自的实现，比如Ubuntu会使用 $rsyslog$ ，Arch使用 $journal$ 。源自 $Berkeley$ 的 $syslogd$ 实现在启动时执行以下步骤：

读取配置文件。通常为 $/etc/syslog.conf$ 的配置文件指定本守护进程可能收取的各种日志消息应该如何处理。这些消息可能被添加到一个文件，或被写到指定用户的登录窗口，或被转发给另一个主机上的 $syslog$ 进程；
创建一个Unix域数据报套接字，给它捆绑路径名 $/var/run/log$ ；
创建一个UDP套接字，给他捆绑端口 $514$ ( $syslog$ 服务使用的端口 )；
打开路径名 $/dev/klog$ ，来自内核中的任何出错消息看着像是这个设备的输入。

此后 $syslog$ 一直在一个无限循环中运行：调用 $select$ 等待 $3$ 个描述符 ( 上述第 $2$ 、$3$ 和 $4$ 步 )，读入日志消息，按照配置文件进行处理。如果接收到 $SIGHUP$ 信号，则重新读取配置文件。
通过创建一个Unix域数据报套接字，我们就可以从自己的守护进程中通过往 $syslogd$ 绑定的路径名发送我们的消息，从而达到发送日志消息的目的。另外，我们也可以创建一个UDP套接字 ( 较新的实现为防止遭受攻击，会禁止套接字的创建 )，通过往环回地址和端口 $514$ 发送我们的消息达到发送日志消息的目的。

2. `syslog`函数

#include <syslog.h>

void syslog(int priority, const char *message, ...);

从守护进程中登记消息的常用技巧就是调用 $syslog$ 函数。本函数最初是为BSD系统开发的，不过如今几乎所有Unix厂商都有提供。$priority$ 是级别 ( $level$ ) 和设施 ( $facility$ ) 两者的组合。$message$ 参数类似于 $printf$ 的格式串，不过增加了 $\%m$ 规范，将 $errno$ 值替换为对应的错误消息，可以在 $message$ 的末尾添加换行符，不过并非必需。

Unix网络编程（5）：DNS

Mon, 07 Feb 2022 15:57:58 +0800

1. 域名系统

DNS中的条目称为资源记录 ( $resource$ $record$ , $RR$ )。

$A$ ：$A$ 记录把一个主机名映射成一个 $32$ 位的IPv4地址；
$AAAA$ ：四 $A$ ( $quad$ $A$ ) 记录把一个主机名映射成一个 $128$ 位的IPv6地址；
$PTR$ ：指针记录 ( $pointer$ $record$ ) 把IP地址映射成主机名。对于IPv4地址，$32$ 地址的 $4$ 字节先反转顺序，每字节都转换成各自的十进制ASCII值后，再添加 $in-addr.arpa$ ；对于IPv6地址，$128$ 位地址中的 $32$ 个四位组先反转顺序，每个四位组都被转换成相应的十六进制ASCII值后，再添加 $ip6.arpa$ ；
$MX$　：$MX$ 记录把一个主机指定作为给定主机的邮件交换器 ( $mail$ $exchanger$ )；
$CNAME$ ：$CNAME$ 代表规范名字 ( $canonical$ $name$ )，常见用法是为常用的服务指派 ( 例如 $ftp$ 和 $www$ ) CNAME记录。如果人们使用这些服务名而不是真实的主机名，那么相应的服务挪到另一个主机时他们也不必知道。

每个组织往往运行一个或多个名字服务器 ( $name$ $server$ )，它们通常就是所谓的 $BIND$ ( $Berkeley$ $Internet$ $Name$ $Domain$ ) 程序。诸如我们编写的客户和服务器等应用程序通过调用称为解析器 ( $resolver$ ) 的函数库中的函数接触DNS服务器。解析器代码通常包含在一个系统函数库中，在构造应用程序时被链编 ( $link-editing$ ) 到应用程序中。解析器使用UDP向本地名字服务器发出查询，如果本地名字服务器不知道答案，通常就会使用UDP在整个因特网上查询其他名字服务器。如果答案太常，超出了UDP消息的承载能力，本地名字服务器和解析器会自动切换到TCP。
不使用DNS也可能获取名字和地址信息。常用的替代方法有静态主机文件 ( 通常是 $/etc/hosts$ 文件 )、网络信息系统 ( $Network$ $Information$ $System$ , $NIS$ ) 以及轻权目录访问协议 ( $Lightweight$ $Directory$ $Access$ $Protocol$ , $LDAP$ )。不幸的是，系统管理员如何配置一个主机以使用不同类型的名字服务是实现相关的。幸运的是，这些差异对于应用程序开发人员来说通常是透明的，我们只需调用诸如 $gethostbyname$ 和 $gethostbyaddr$ 这样的解析器函数。

Unix网络编程（4）：基本UDP/SCTP套接字编程

Thu, 03 Feb 2022 16:08:32 +0800

1. 基本`UDP`套接字编程

1.1 `recvfrom`和`sendto`函数

$recvfrom$ 和 $sendto$ 类似于标准 $read$ 和 $write$ 函数，不过需要三个额外的参数。

#include <sys/socket.h>

ssize_t recvfrom(int sockfd, void *buff, size_t nbytes, int flags,
  struct sockaddr *from, socklen_t *addrlen);

ssize_t sendto(int sockfd, const void *buff, size_t nbytes, int flags,
  const struct sockaddr *to, socklen_t addrlen);

// 成功则返回读或写的字节数，出错返回-1

$sendto$ 的 $to$ 参数指向一个含有数据报接收者的协议地址的套接字地址结构，其大小由 $addrlen$ 指定。$recvfrom$ 的 $from$ 参数指向一个将由该参数在返回时填写数据报发送者的协议地址的套接字地址结构，其大小由 $addrlen$ 返回给调用者。写一个长度为 $0$ 的数据报是可行的。在UDP情况下，这回形成一个只包含一个IP首部和一个 $8$ 字节UDP首部而没有数据的IP数据报。这也意味着对于数据报协议，$recvfrom$ 返回 $0$ 值是可以接受的，并不像TCP一样代表对端连接关闭。如果 $recvfrom$ 的 $from$ 参数是一个空指针，那么相应的长度参数 $addrlen$ 也必须是一个空指针。
UDP输出操作成功仅仅表示在接口输出队列中具有存放所形成IP数据报的空间，而错误会在之后返回，称为异步错误 ( $asynchronous$ $error$ )。一个基本规则是：对于一个UDP套接字，由它引发的异步错误并不返回给它，除非它已连接。考虑在单个UDP套接字上接连发送 $3$ 个数据报给 $3$ 个不同的服务器的一个UDP客户，其中有 $2$ 个数据报被正确递送，但是第三个主机没有运行服务器，于是返回一个ICMP端口不可达错误。发送这 $3$ 个数据报的客户需要知道引发该错误的数据报的目的地址以区分究竟是哪一个数据报引发错误，如果 $recvfrom$ 仅仅设置 $errno$ ，则无法返回出错数据报的IP地址的端口。因此，仅在进程已将其UDP套接字连接到一个对端之后，这些异步错误才会返回给进程。

1.2 `connect`函数

我们可以给UDP套接字调用 $connect$ ，然而这样做的结果与TCP连接大相径庭：没有三次握手，而是更类似于指定对端地址。内核只是检查是否存在立即可知的错误，记录对端的IP地址和端口号，然后立即返回到调用进程。对于已连接的UDP套接字，与默认未连接的UDP套接字相比，有以下变化：

不能给输出操作指定目的IP地址和端口号。也就是说，不使用 $sendto$ ，而是改为使用 $write$ 或 $send$ 。写到已连接UDP套接字上的任何内容都会自动发送到由 $connect$ 指定的协议地址；
不必使用 $recvfrom$ 获取数据报，而是使用 $read$ 、$recv$ 或 $recvmsg$ 。在一个已连接UDP套接字上，由内核为输入操作返回的数据报只有那写来自 $connect$ 所指定协议地址的数据报。目的地为这个已连接UDP套接字的本地协议地址，发出地不是该套接字早先连接到的协议地址的数据报，不会被投递到该套接字。这就限制了一个已连接UDP套接字只能与一个对端交换数据；
由已连接UDP套接字引发的异步错误会返回给它们所在的进程，未连接UDP套接字不会接收任何异步错误。

拥有一个已连接UDP套接字的进程可出于以下两个目的之一再次调用 $connect$ ：

Unix网络编程（3）：I/O复用

Wed, 02 Feb 2022 15:04:28 +0800

1. `I/O`模型

Unix下有 $5$ 种可用的I/O模型：阻塞式I/O、非阻塞式I/O、I/O复用、信号驱动式I/O和异步I/O。

1.1 阻塞式`I/O`

最流行的I/O模型是阻塞式I/O ( $blocking$ $I/O$ ) 模型。默认情形下，所有的套接字都是阻塞的。

1.2 非阻塞式`I/O`

进程把一个套接字设置成非阻塞式是在通知内核：当所请求的I/O操作非得把本进程置于休眠状态才能完成时，不要把本进程置于休眠状态，而是返回一个错误。

当一个应用进程像这样对一个非阻塞描述符循环调用 $recvfrom$ 时，我们称之为轮询 ( $polling$ )。应用进程持续轮询内核，以查看某个操作是否就绪，这么做往往耗费大量CPU时间。不过这种模型偶尔也会遇到，通常是在专门提供某一种功能的系统中才有。

1.3 `I/O`复用

通过I/O复用，我们可以调用 $select$ 或 $poll$ ，阻塞在这两个系统调用中的某一个之上，而不是阻塞在真正的I/O系统调用上。

1.4 信号驱动式`I/O`

我们也可以使用信号，让内核在描述符就绪时发送 $SIGIO$ 信号通知我们。

我们首先开启套接字的信号驱动I/O功能，并通过 $sigaction$ 系统调用安装一个信号处理函数。该系统调用立即返回，我们的进程继续工作。当数据报准备好被读取时，内核就为该进程产生一个 $SIGIO$ 信号。我们随后既可以在信号处理函数中调用 $recvfrom$ 读取数据报，并通知主循环数据已准备好待处理，也可以立即通知主循环，让它读取数据报。

1.5 异步`I/O`

异步I/O ( $asynchronous$ $I/O$ ) 由POSIX规范定义。一般地说，这些函数的工作机制是：告知内核启动某个操作，并让内核在整个操作（包括将数据从内核复制到我们自己的缓冲区）完成后通知我们。这种模型与前一节介绍的信号驱动模型的主要区别在于：信号驱动式I/O是由内核通知我们何时可以启动一个I/O操作，异步I/O是由内核通知我们I/O操作何时完成。

我们调用 $aio_-read$ 函数，给内核传递描述符、缓冲区指针、缓冲区大小和文件偏移，并告诉内核当整个操作完成时如何通知我们。该系统调用会立即返回，而且在等待I/O完成期间，我们的进程不被阻塞。

2. `select`函数

$select$ 函数允许进程指示内核等待多个事件中的任何一个发生，并只在有一个或多个事件发生或经历一段指定时间后才唤醒。

#include <sys/select.h>
#include <sys/time.h>

// 存在就绪描述符则返回其数目，超时返回0，出错返回-1
int select(int maxfdp1, fd_set *readset, fd_set *writeset,
  fd_set *exceptset, const struct timeval *timeout);

strcut timeval {
  long tv_sec;  // seconds
  long tv_usec;  // microseconds

$timeval$ 参数有以下三种可能：

Unix网络编程（2）：基本TCP套接字编程

Sat, 29 Jan 2022 18:38:32 +0800

1. 基本`TCP`套接字编程

1.1 `socket`函数

为了执行网络I/O，进程必须做的第一件事就是调用 $socket$ 函数。

#include <sys/socket.h>

// 成功返回套接字描述符，失败返回-1
int socket(int family, int type. int protocol);

$family$ 为协议族，由于历史问题，一些实现中还存在以 $PF$ 开头的协议族，但基本等价；$type$ 指明套接字类型；$protocol$ 为某个协议类型常值。

$family$	说明
$AF_-INET$	`IPv4`协议
$AF_-INET6$	`IPv6`协议
$AF_-LOCAL$	`Unix`域协议
$AF_-ROUTE$	路由套接字
$AF_-KEY$	密钥套接字

$type$	说明
$SOCK_-STREAM$	字节流套接字
$SOCK_-DGRAM$	数据报套接字
$SOCK_-SEQPACKET$	有序分组套接字
$SOCK_-RAW$	原始套接字

$protocol$	说明
$IPPROTO_-TCP$	`TCP`传输协议
$IPPROTO_-UDP$	`UDP`传输协议
$IPPROTO_-SCTP$	`SCTP`传输协议

组合	$AF_-INET$	$AF_-INET6$	$AF_-LOCAL$	$AF_-ROUTE$	$AF_-KEY$
$SOCK_-STREAM$	`TCP`｜`SCTP`	`TCP`｜`SCTP`	有效
$SOCK_-DGRAM$	`UDP`	`UDP`	有效
$SOCK_-SEQPACKET$	`SCTP`	`SCTP`	有效
$SOCK_-RAW$	`IPv4`	`IPv6`		有效	有效

1.2 `connect`函数

TCP客户使用 $connect$ 函数来与TCP服务器建立连接。

Unix网络编程（1）：套接字编程简介

Wed, 26 Jan 2022 17:10:43 +0800

1. 传输层

TCP建立一个连接需要三次握手：

服务器准备接受外部连接，通常通过调用 $socket$ 、$bind$ 、$listen$ 这 $3$ 个函数完成，称为被动打开 ( $passive$ $open$ )；
客户端通过调用 $connect$ 发起主动打开 ( $active$ $open$ )，即发送一个SYN报文；
服务器确认 ( ACK ) 客户端的SYN，同时也发送一个SYN；
客户端确认服务器的SYN。

TCP终止一个连接需要四次挥手：

某个进程调用 $close$ ，称为主动关闭 ( $active$ $close$ )，该端发送一个FIN报文；
对端接受FIN，执行被动关闭 ( $passive$ $close$ )。这个FIN由TCP确认，接收也作为一个文件结束符 ( $end-of-file$ , $EOF$ ) 传递给接收端应用程序 ( 放在已排队等候该应用进程接收的任何其他数据之后 )；
一段时间后，接收到EOF的进程调用 $close$ 关闭套接字，并发送一个FIN报文；
接收到FIN的原端TCP确认。

TCP状态转换图可参考TCP、UDP和DNS简介。
SCTP建立一个连接的过程为：

服务器准备接受外部连接，通常通过调用 $socket$ 、$bind$ 、$listen$ 这 $3$ 个函数完成，称为被动打开；
客户端通过调用 $connect$ 或者发送一个隐式打开该关联的消息进行主动打开，从而发送一个INIT消息，告知服务器客户端的IP地址清单、初始序列号、分组起始标记、客户端请求的外出流数目以及客户端能支持的外出流的数目；
服务器以一个INIT ACK消息确认，其中含有服务器的IP地址清单、初始序列号、起始标记、请求的外出流数目、支持的外出流数目和一个状态cookie，包含服务器用于确认本次连接有效所需的所有状态；
客户端以一个COOKIE ECHO消息回射状态cookie；
服务器以一个COOKIE ACK消息确认cookie正确，于是连接建立。

        SCTP不像TCP那样允许”半关闭“的连接，而是当某一端关闭时，另一端必须停止发送新数据，在发送完所有队列中的数据后关闭。
        一个TCP连接的套接字对 ( $socket$ $pair$ ) 是一个定义该连接的两个端点的四元组：本地IP地址、本地TCP端口号、外地IP地址、外地TCP端口号。在两个端点均非多宿这一最简单情形下，SCTP和TCP所用的四元组套接字对一致。然而在某个关联的任何一个端点为多宿的情形下，同一个关联可能需要多个四元组标识 ( IP地址各不相同，但端口号一致 )。标识每个端点的两个值 ( IP地址和端口号 ) 通常称为一个套接字。
        并发服务器中主服务器循环通过派生一个子进程来处理每个新连接。假设服务器在端口 $21$ 上被动打开，等待请求，此时我们可使用 $\{$ $*:21$ , $*:*$ $\}$ 指出服务器的套接字对，其中外地IP地址和外地端口都没有指定，记为 $*.*$ ，我们称为监听套接字 ( $listening$ $socket$ )。当服务器接受到一个客户连接时，会 $fork$ 一个子进程，并将连接交由子进程处理，这时产生的套接字称为 已连接套接字 ( $connected$ $socket$ )。

秋招面试总结

Tue, 07 Sep 2021 22:20:53 +0800

1. 腾讯-WXG-微信支付

1.1 一面

C++了解吗 ( 不了解就没问了 )
算法题：无序数组有序排列的最大相邻差值 ( 跟我说不能排序，搜了下答案是桶排序，迷惑 )
算法题：$100$ 个样本找病毒
算法题：二叉树深度 ( 递归和迭代 )
实习项目
Linux了解吗 ( 怕他往下问就说不了解了 )
协程了解吗？
什么时候用协程比较好
协程切换的时候变化的东西和不变的东西 ( 没听懂啥意思 )
唠家常 ( 哪里人，想在哪工作 )
算法题：数组中的重复元素

总结：因为跟他说技术栈是Go所以就问协程了，第一道算法题没做出来，中间问题没听懂，但是莫名其妙地过了。

1.2 面委会一面

实习项目
数据库索引
为什么要用B+树
Redis和MySQL区别
Redis的I/O模型
$epoll$ ， $LT$ 和 $ET$
Redis持久化
其他存储有了解吗 ( 跟他说Kafka，他说Kafka不是存储😂 )
Kafka介绍下
代码：直播间有热度，可以创建删除直播间，运营人员半小时一次查看 $Top 100$ 的直播间
代码题展开，$Map$ 的实现，常用并发结构的实现
学过C++吗

总结：被干碎了，代码题还看漏了，写成实时排序了，其实半小时一次并不用实时维护。

1.3 面委会二面

实习项目的技术难题和挑战
实习项目继续问
RPC的理解
Redis的LRU
LRU和LFU
海量数据排序 ( 内存装不下 )
参加了啥竞赛 ( 没有 )
在学校时候的优势和劣势
学习心得 ( 你项目实践比较少啊😂 )

总结：不知道面了个啥，感觉更像是个懂技术的HR。

ThreadPoolExecutor原理

Thu, 26 Aug 2021 17:13:59 +0800

1. 线程池介绍

为什么使用线程池？

创建/销毁线程需要消耗系统资源，线程池可以复用已经创建的线程；
控制并发数；
统一管理线程。

2. 构造方法

/*
    @param corePoolSize    核心线程数最大值
    @param maximumPoolSize 线程总数最大值
    @param keepAliveTime   非核心线程超时时长
    @param unit            keepAliveTime的时间单位
    @param workQueue       维护待执行的Runnable对象的阻塞队列
    @param threadFactory   线程工厂
    @param handler         拒绝处理策略
*/
public ThreadPoolExecutor(@Range(from = 0, to = java.lang.Integer.MAX_VALUE) int corePoolSize,
                          @Range(from = 1, to = java.lang.Integer.MAX_VALUE) int maximumPoolSize,
                          @Range(from = 0, to = java.lang.Long.MAX_VALUE) long keepAliveTime,
                          @NotNull TimeUnit unit,
                          @NotNull BlockingQueue<Runnable> workQueue,
                          @NotNull ThreadFactory threadFactory,
                          @NotNull RejectedExecutionHandler handler) {
    if (corePoolSize < 0 ||
        maximumPoolSize <= 0 ||
        maximumPoolSize < corePoolSize ||
        keepAliveTime < 0)
        throw new IllegalArgumentException();
    if (workQueue == null || threadFactory == null || handler == null)
        throw new NullPointerException();
    this.acc = System.getSecurityManager() == null ?
            null :
            AccessController.getContext();
    this.corePoolSize = corePoolSize;
    this.maximumPoolSize = maximumPoolSize;
    this.workQueue = workQueue;
    this.keepAliveTime = unit.toNanos(keepAliveTime);
    this.threadFactory = threadFactory;
    this.handler = handler;
}

public ThreadPoolExecutor(@Range(from = 0, to = java.lang.Integer.MAX_VALUE) int corePoolSize,
                          @Range(from = 1, to = java.lang.Integer.MAX_VALUE) int maximumPoolSize,
                          @Range(from = 0, to = java.lang.Long.MAX_VALUE) long keepAliveTime,
                          @NotNull TimeUnit unit,
                          @NotNull BlockingQueue<Runnable> workQueue) {
    this(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue,
         Executors.defaultThreadFactory(), defaultHandler);
}

public ThreadPoolExecutor(@Range(from = 0, to = java.lang.Integer.MAX_VALUE) int corePoolSize,
                          @Range(from = 1, to = java.lang.Integer.MAX_VALUE) int maximumPoolSize,
                          @Range(from = 0, to = java.lang.Long.MAX_VALUE) long keepAliveTime,
                          @NotNull TimeUnit unit,
                          @NotNull BlockingQueue<Runnable> workQueue,
                          @NotNull ThreadFactory threadFactory) {
    this(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue,
            threadFactory, defaultHandler);
}

public ThreadPoolExecutor(@Range(from = 0, to = java.lang.Integer.MAX_VALUE) int corePoolSize,
                          @Range(from = 1, to = java.lang.Integer.MAX_VALUE) int maximumPoolSize,
                          @Range(from = 0, to = java.lang.Long.MAX_VALUE) long keepAliveTime,
                          @NotNull TimeUnit unit,
                          @NotNull BlockingQueue<Runnable> workQueue,
                          @NotNull RejectedExecutionHandler handler) {
    this(corePoolSize, maximumPoolSize, keepAliveTime, unit, workQueue,
            Executors.defaultThreadFactory(), handler);
}

3. 策略

线程池本身有一个调度线程，管理整个线程池里的各种任务和事务，例如创建线程、销毁线程、任务队列管理、线程队列管理等。

进程、线程和协程

Wed, 25 Aug 2021 17:25:27 +0800

	进程	线程	协程
`CPU`	系统负责执行线程	一个进程含有多个线程，系统分配线程在不同的`CPU`上执行	线程上执行
内存	进程管理自己的内存区域	多线程共享进程的内存区域	同线程
栈		系统负责在内存中分配调用栈，默认为 $8MB$	用户程序在堆上分配栈，切换的时候修改 $SP$ 、$PC$ 、$BP$
切换方式		时间片耗尽后触发中断处理程序，内核负责切换线程	主动切换，让出`CPU`
切换内容	通用寄存器，$PC$ 寄存器，页表寄存器，`TLB`，`CPU`缓存	通用寄存器，$PC$ 寄存器，`CPU`缓存	通用寄存器，$PC$ 寄存器
上下文	$task_-struct$ ，页表	$task_-struct$ ，页表	运行栈，寄存器

1. `CPU`和内存

操作系统为进程分配了一个专门的数据结构称为进程控制块 ( $Process\ \ Control\ \ Block$ ，$PCB$ )。系统利用PCB来描述进程基本情况和运行状态，进而实现对进程的控制和管理。程序段、相关数据段和PCB构成了进程实体。PCB内的信息包括：

进程描述信息：进程标识符 ( $PID$ ) 和用户标识符 ( $UID$ )；
进程控制和管理信息：进程状态信息，进程优先级，代码运行入口，程序外存地址，处理机占用时间等；
资源分配清单：代码段指针、数据段指针、堆栈段指针和文件描述符等；
处理机相关信息：通用寄存器，地址寄存器，控制寄存器，状态字等。

线程的最直接理解就是轻量级进程，是CPU的基本执行单元，也是程序执行的最小单元，包括：

线程ID；
程序计数器；
寄存器；
堆栈。

        线程是进程中的一个实体，是系统独立调度和分派的基本单位，只拥有一些运行中必不可少的资源，共享其所在线程的全部资源。在多线程操作系统中，进程的执行实际上是进程中的某个线程正在执行。Linux系统中进程和线程都使用 $task_-struct$ 结构描述，存储在一个双端循环列表中，列表存储在内核栈的末尾。
        线程的实现可以分为两类，用户级线程 ( $User-Level\ \ Thread$ ) 和内核级线程 ( $Kernel-Level\ \ Thread$ )。用户级线程中，有关线程管理的所有工作都交由应用程序完成；内核级线程中，线程管理的所有工作都交由内核完成，应用程序只有一个到内核级线程的编程接口，内核为进程及其内部的每个线程维护上下文信息。
        协程并不是一个新概念，它在 $1958$ 年就被提出。协程就是一个子任务，特点是非抢占式的调度。协程会自己判断运行状况，当满足一定条件就会主动让出CPU给其他协程，而进程或者线程的切换需要进入内核态交给内核处理。协程其实就是用户级线程。协程中的信息只包括运行栈和寄存器，后者决定了程序在代码中的执行位置。

HashMap源码解读

Mon, 23 Aug 2021 15:01:55 +0800

1. 字段

字段设置为 $transient$ ，因为 $HashMap$ 通过 $Object.hashCode(\ )$ 获取哈希值，并通过哈希值与桶个数取模确定对象。$Object.hashCode(\ )$ 是一个本地方法，依赖于JVM实现，存在跨平台问题，所有 $HashMap$ 在序列化时会先保存所有 $Key$ ，再在反序列化时重新插入。

// 最大容量
static final int MAXIMUM_CAPACITY = 1 << 30;

// 默认负载因子，大小/容量超过这个比例就会扩容
static final float DEFAULT_LOAD_FACTOR = 0.75f;

// 当桶中节点数不小于该值时树化
// 树节点大小是常规节点两倍，应该在有足够的节点后树化
static final int TREEIFY_THRESHOLD = 8;

// 当桶中节点数小于该值时链表化
// 不设为TREEIFY_THRESHOLD，避免抖动
static final int UNTREEIFY_THRESHOLD = 6;

// 当容量不小于该值时才会树化，否则会优先扩容
// 应当至少为 4 * TREEIFY_THRESHOLD
static final int MIN_TREEIFY_CAPACITY = 64;

// 初次使用时初始化，长度为 2 的幂次
transient Node<K,V>[] table;

// entrySet() 缓存
transient Set<Map.Entry<K,V>> entrySet;

// 改变次数，每次修改都会增加
transient int modCount;

2. 构造函数

public HashMap(int initialCapacity, float loadFactor) {
    if (initialCapacity < 0)
        throw new IllegalArgumentException("Illegal initial capacity: " +
                                            initialCapacity);
    if (initialCapacity > MAXIMUM_CAPACITY)
        initialCapacity = MAXIMUM_CAPACITY;
    if (loadFactor <= 0 || Float.isNaN(loadFactor))
        throw new IllegalArgumentException("Illegal load factor: " +
                                            loadFactor);
    this.loadFactor = loadFactor;
    // tableSizeFor会获得不小于当前数字的最小的2的幂次
    this.threshold = tableSizeFor(initialCapacity);
}

public HashMap(int initialCapacity) {
    this(initialCapacity, DEFAULT_LOAD_FACTOR);
}

public HashMap() {
    this.loadFactor = DEFAULT_LOAD_FACTOR; // all other fields defaulted
}

public HashMap(Map<? extends K, ? extends V> m) {
    this.loadFactor = DEFAULT_LOAD_FACTOR;
    putMapEntries(m, false);
}

/** 计算大于等于输入参数的最小的 2 的幂次 */
static final int tableSizeFor(int cap) {
    int n = cap - 1;
    n |= n >>> 1;
    n |= n >>> 2;
    n |= n >>> 4;
    n |= n >>> 8;
    n |= n >>> 16;
    return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : n + 1;
}

3. 内部类

static class Node<K,V> implements Map.Entry<K,V> {
    final int hash;
    final K key;
    V value;
    Node<K,V> next;

    public final int hashCode() { return Objects.hashCode(key) ^ Objects.hashCode(value); }
}

4. 插入

// 高低16位异或
static final int hash(Object key) {
    int h;
    return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}

public V put(K key, V value) { return putVal(hash(key), key, value, false, true); }

// @param onlyIfAbsent 如果为true，则不会改变已存在的value
// @param evict        如果为false，说明处于构造模式
final V putVal(int hash, K key, V value, boolean onlyIfAbsent, boolean evict) {
    Node<K,V>[] tab; Node<K,V> p; int n, i;
    if ((tab = table) == null || (n = tab.length) == 0)
        // 表为空，创建表
        n = (tab = resize()).length;
    if ((p = tab[i = (n - 1) & hash]) == null)
        // 对应位置为空，直接创建节点
        tab[i] = newNode(hash, key, value, null);
    // 碰撞处理
    else {
        Node<K,V> e; K k;
        if (p.hash == hash &&
            ((k = p.key) == key || (key != null && key.equals(k))))
            // 节点key相同
            e = p;
        else if (p instanceof TreeNode)
            // 树状节点，向树中插入
            e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value);
        else {
            for (int binCount = 0; ; ++binCount) {
                if ((e = p.next) == null) {
                    // 尾插法
                    p.next = newNode(hash, key, value, null);
                    if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st
                        // 超过阈值，树化
                        treeifyBin(tab, hash);
                    break;
                }
                if (e.hash == hash &&
                    ((k = e.key) == key || (key != null && key.equals(k))))
                    // 节点key相同
                    break;
                p = e;
            }
        }
        if (e != null) { // existing mapping for key
            V oldValue = e.value;
            // 更新值
            if (!onlyIfAbsent || oldValue == null)
                e.value = value;
            afterNodeAccess(e);
            return oldValue;
        }
    }
    ++modCount;
    if (++size > threshold)
        // 超过阈值，扩容
        resize();
    afterNodeInsertion(evict);
    return null;
}

// 扩容方法
final Node<K,V>[] resize() {
    Node<K,V>[] oldTab = table;
    int oldCap = (oldTab == null) ? 0 : oldTab.length;
    int oldThr = threshold;
    int newCap, newThr = 0;
    if (oldCap > 0) {
        if (oldCap >= MAXIMUM_CAPACITY) {
            threshold = Integer.MAX_VALUE;
            return oldTab;
        }
        else if ((newCap = oldCap << 1) < MAXIMUM_CAPACITY &&
                    oldCap >= DEFAULT_INITIAL_CAPACITY)
            // 两倍扩容
            newThr = oldThr << 1; // double threshold
    }
    else if (oldThr > 0) // initial capacity was placed in threshold
        newCap = oldThr;
    else {               // zero initial threshold signifies using defaults
        newCap = DEFAULT_INITIAL_CAPACITY;
        newThr = (int)(DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY);
    }
    if (newThr == 0) {
        float ft = (float)newCap * loadFactor;
        newThr = (newCap < MAXIMUM_CAPACITY && ft < (float)MAXIMUM_CAPACITY ?
                    (int)ft : Integer.MAX_VALUE);
    }
    // 设置新阈值并创建新表
    threshold = newThr;
    @SuppressWarnings({"rawtypes","unchecked"})
    Node<K,V>[] newTab = (Node<K,V>[])new Node[newCap];
    table = newTab;
    if (oldTab != null) {
        // 迁移节点
        for (int j = 0; j < oldCap; ++j) {
            Node<K,V> e;
            if ((e = oldTab[j]) != null) {
                oldTab[j] = null;
                if (e.next == null)
                    // 没有碰撞
                    newTab[e.hash & (newCap - 1)] = e;
                else if (e instanceof TreeNode)
                    // 树分裂，这一步会判断是否链表化
                    ((TreeNode<K,V>)e).split(this, newTab, j, oldCap);
                else { // preserve order
                    // 链表分裂
                    Node<K,V> loHead = null, loTail = null;
                    Node<K,V> hiHead = null, hiTail = null;
                    Node<K,V> next;
                    do {
                        next = e.next;
                        if ((e.hash & oldCap) == 0) {
                            if (loTail == null)
                                loHead = e;
                            else
                                loTail.next = e;
                            loTail = e;
                        }
                        else {
                            if (hiTail == null)
                                hiHead = e;
                            else
                                hiTail.next = e;
                            hiTail = e;
                        }
                    } while ((e = next) != null);
                    if (loTail != null) {
                        loTail.next = null;
                        newTab[j] = loHead;
                    }
                    if (hiTail != null) {
                        hiTail.next = null;
                        newTab[j + oldCap] = hiHead;
                    }
                }
            }
        }
    }
    return newTab;
}

5. 删除

public V remove(Object key) {
    Node<K,V> e;
    return (e = removeNode(hash(key), key, null, false, true)) == null ?
        null : e.value;
}

// @param value      值
// @param matchValue true表示只有value相同时才会移除
// @param movable    false则移除时不会移动其他节点
final Node<K,V> removeNode(int hash, Object key, Object value,
                            boolean matchValue, boolean movable) {
    Node<K,V>[] tab; Node<K,V> p; int n, index;
    // 表存在、节点存在
    if ((tab = table) != null && (n = tab.length) > 0 &&
        (p = tab[index = (n - 1) & hash]) != null) {
        Node<K,V> node = null, e; K k; V v;
        // 查找节点
        if (p.hash == hash &&
            ((k = p.key) == key || (key != null && key.equals(k))))
            node = p;
        else if ((e = p.next) != null) {
            if (p instanceof TreeNode)
                node = ((TreeNode<K,V>)p).getTreeNode(hash, key);
            else {
                do {
                    if (e.hash == hash &&
                        ((k = e.key) == key ||
                            (key != null && key.equals(k)))) {
                        node = e;
                        break;
                    }
                    p = e;
                } while ((e = e.next) != null);
            }
        }
        // 找到对应节点
        if (node != null && (!matchValue || (v = node.value) == value ||
                                (value != null && value.equals(v)))) {
            if (node instanceof TreeNode)
                // 树移除节点，这一步如果红黑树太小会链表化
                ((TreeNode<K,V>)node).removeTreeNode(this, tab, movable);
            else if (node == p)
                tab[index] = node.next;
            else
                p.next = node.next;
            ++modCount;
            --size;
            afterNodeRemoval(node);
            return node;
        }
    }
    return null;
}

6. 区别

JDK1.7使用头插法，JDK1.8使用尾插法，避免多线程同时扩容时的死循环；
JDK1.7是先扩容后插入的，JDK1.8反过来，避免无效扩容；
JDK1.7只有数组+链表，JDK1.8引入红黑树；

I/O多路复用

Sun, 22 Aug 2021 15:30:25 +0800

1. 基本概念

        操作系统内核 ( $kernel$ ) 是操作系统的核心，独立于普通应用程序，可以访问受保护的内存空间，也有权访问所有底层硬件设备。为了保证用户进程不能直接操作内核，操作系统将内存空间划为两部分，内核空间和用户空间。对于linux系统，如果是 $32$ 位系统，虚拟内存中最高的 $1G$ 字节 ( $0xC0000000 \sim 0xFFFFFFFF$ ) 为内核空间；如果是 $64$ 位系统，指针的前 $16$ 位保留，从而只有 $48$ 位寻址空间，于是最高的 $128T$ 字节 ( $0x0000000000000000 \sim 0x00007FFFFFFFF000$ ) 作为系统空间，中间部分 ( $0x00007FFFFFFFFFFF \sim 0xFFFF800000000000$ ) 作为保留，其余部分为用户空间。
        正在执行的进程由于某些期待的事件未发生，如资源请求失败或者等待某些操作完成等，会自动执行阻塞原语，使自己由运行态变为阻塞态。进程的阻塞是一种主动行为，只有处于运行态的进程才可以触发，并且阻塞后不占用CPU资源。
        文件描述符 ( $fd$ ) 是一个指向文件引用的概念，在形式上是一个非负整数，实际上是一个索引值，指向内核打开文件表中的对应记录。打开文件表中记录了文件的属性，包括磁盘位置、访问权限、文件位置指针以及打开计数。
        缓存I/O又称为标准I/O，大多数文件系统的默认I/O操作都是缓存I/O。在Linux中，操作系统会将I/O数据缓存在文件系统的 $Page\ \ Cache$ 中，即数据会先被拷贝到操作系统内核的缓冲区中，然后才会从操作系统内核的缓冲区拷贝到应用程序的地址空间。
        在BIO模式下，当线程接收一个请求后，在等待I/O的时间内，调用会被阻塞，无法接受其他请求。在多线程环境下，如果想要接受大量请求，就需要创建大量线程，占用大量系统空间，并且线程切换会带来很大的开销。$10000$ 个线程真正发生读写的实际的线程数不会超过 $20\%$ 。
        在NIO模式下，当线程接收一个请求后，会加入 $fd_-set$ 集合，每次轮询集合接收数据，如果没有数据会返回错误。每次都要轮询所有集合，包括未发生实际读写的 $fd$ ，会浪费CPU资源。
        在I/O多路复用模式下，服务端通过 $select$ / $poll$ / $epoll$ 等系统调用获取 $fd$ 列表，遍历有事件的 $fd$ 进行数据接收，可以支持更多并发连接请求。

I/O多路复用是一种同步I/O模型，多路指网络连接，复用指一个线程，即一个线程可以监视多个文件句柄；
一旦某个文件句柄就绪，就可以通知应用程序进行相应的读写操作；
没有文件句柄就会阻塞线程。

2. `select`

$select$ 是仅仅知道了有I/O事件发生，但是无法确定是哪几个流 ( 一个或多个，甚至全部 )，只能无差别的轮询所有流，直到找出所有能读出或写入数据的流，具有 $O(n)$ 的无差别轮询复杂度。

缓存一致性协议MESI

Mon, 16 Aug 2021 11:02:05 +0800

        高速缓冲存储器一致性 ( $Cache\ \ coherence$ )，也称缓存一致性，是指在采用层次结构存储系统的计算机系统中，保证告诉缓冲存储器中数据与主存储器中数据相同的机制。在有多个CPU的多处理机系统中特别容易出现高速缓存中数据不一致的问题。
        在CPU缓存设计中，L1高速缓存包含指令缓存和数据缓存，位于CPU芯片上，访问速度几乎和寄存器一样快。L2高速缓存在L1和主存之间，连接到存储器总线或者高速缓存总线上。有些高性能系统还会在存储器总线上设置L3高速缓存。L1和L2是每个CPU内核间独立的，L3是所有CPU内核间共享的。
        对于单核CPU来说，数据更新时缓存更新只用考虑自己的就行了，主要有两种处理方法。写回法 ( $write\ \ back$ )，是当处理器执行写操作时，信息只写入cache，当cache中的数据被替换出去时写回主存。为了减少内存写操作，cache中通常还会设置一个脏位 ( $dirty\ \ bit$ )，标识该块在被载入后是否发生了更新。直写法 ( $write\ \ through$ ) 是当处理器执行写操作时，既向cache中写入也向主存中写入。直写法会造成大量写内存操作，需要设置一个缓冲来减少硬件冲突，称为写缓冲器 ( $write\ \ buffer$ )，通常不超过 $4$ 个缓存块的大小，也适用于写回法。
        相比于单核CPU，多核CPU除了要保证L1和L2最新外还要考虑到其他核中L1和L2的实时性和有效性。MESI协议是一个基于失效的缓存一致性协议，是支持写回缓存的最常用协议。该协议对总线上的操作进行监听，即核 $A$ 可以窥探到核 $B$ 对过期值的读操作，并更新主存中的过期值。MESI把cache中的数据分为几个状态：

状态	描述	监听
$Invalid$	该`cache`字段失效	无
$Shared$	字段数据一致并且多核`cache`共享该字段	监听其他缓存使该字段无效或者变为 $Exclusive$ 的请求，监听到对应事件后会将该字段设为 $Invalid$
$Exclusive$	字段数据一致并且只在当前核`cache`中独有	监听其他缓存读主存中该字段的操作，监听到对应事件后将该字段变为 $Shared$
$Modified$	该字段有效但是与主存不一致，只存在于当前核`cache`中	监听所有试图读该字段对应主存字段的操作，该操作会被延迟到当前缓存字段写回主存并将状态设为 $Shared$ 之后执行

事件	描述
$Local\ \ Read$	读取本地`cache`字段
$Local\ \ Write$	写入本地`cache`字段
$Remote\ \ Read$	其他`cache`读取字段
$Remote\ \ Write$	其他`cache`写入字段

        对于 $Modified$ 和 $Exclusive$ 状态，数据是精确的，而 $Shared$ 状态可能是非一致的。如果一个处于 $Shared$ 的缓存字段作废了，另一个缓存实际上可能已经独享了该缓存字段，但是该缓存不会转为 $Exclusive$ ，因为其他缓存并不会广播他们作废该缓存字段的通知。如果一个CPU想修改一个处于 $Shared$ 状态的缓存字段，总线事务需要将所有该缓存字段的副本变为 $Invalid$ 状态，而修改 $Exclusive$ 状态的缓存字段不需要总线事务。
        缓存的一致性消息传递是需要时间的，这就使其切换时产生延迟。当一个缓存被切换状态时其他缓存收到消息完成各自的切换并且发出回应消息这么长一段时间中CPU都会等待所有缓存响应完成。为了避免这种CPU运算能力的浪费，$Store\ \ Buffer$ ( 写缓存 ) 被引入。处理器会将想要写入主存的值写到 $Store\ \ Buffer$ 中再去处理其他事情。
        同样的，CPU在收到无效化通知后，也不会立即将数据无效化，因为发出通知的CPU在等待响应，而无效化需要时间。所以CPU会将数据存入无效化队列，在存入之后就返回 $Ack$ ，以免阻塞CPU。
        写缓冲器和无效化队列也会带来新的问题：

MySQL笔记

Mon, 21 Jun 2021 20:33:31 +0800

1. 架构

大体来说，MySQL可以分为Server层和存储引擎层两部分。Server层包括连接器、查询缓存、分析器、优化器、执行器等，以及所有的内置函数，所有跨存储引擎功能都在这一层实现。而存储引擎层负责数据的存储和提取。其架构模式是插件式的，支持InnoDB、MyISAM、Memory等多个引擎。不同的存储引擎共用一个Server层，也就是从连接器到执行器的部分。

连接器：连接器负责跟客户端建立连接、获取权限、维持和管理连接。数据库里面，长连接是指连接成功后，如果客户端持续有请求，则一直使用同一个连接。短连接则是指每次执行完很少的几次查询就断开连接。建立连接的过程通常比较复杂，所以应尽量使用长连接。但是全部使用长连接后，有时候MySQL内存占用会很高，因为MySQL在执行过程中临时使用的内存是在连接对象里的，只有在断开连接时才释放。
查询缓存：MySQL会在执行语句之前先在查询缓存中查询。但是查询缓存的失效很频繁，只要有一个表更新，表上所有缓存都会失效。对于更新压力大的数据库来讲，命中率会很低。MySQL在 $8.0$ 版本移除了查询缓存功能。
分析器：分析器会对语句做语法分析，判断语句是否存在错误，同时理解语句要执行的操作。
优化器：优化器是在表中存在多个索引的时候，决定使用哪个索引；或者在一个语句有多表关联时，决定表的连接顺序。
执行器：在开始执行之前，会检查是否对表具有查询权限。如果有权限，就打开表执行。打开表的时候，执行器就会根据表的引擎定义，去使用这个引擎提供的接口。

        一个InnoDB表包含两个部分，即表结构定义和数据。表结构定义的占用空间很小，在MySQL 8.0版本以前，表结构是存在以 $.frm$ 为后缀的文件里，而MySQL 8.0版本已经允许把表结构定义放在系统数据表中了。表数据既可放在共享表空间里，也可以是单独的文件，从MySQL 5.6.6开始，默认是存储在一个以 $.ibd$ 为后缀的文件中的。对于放在共享表空间中的表，即使通过 $DROP$ 命令删除后，空间也不会回收。在删除的过程中，InnoDB会查找聚簇索引，将对应的记录标记为删除，而不是真正删除，目的是为以后插入新数据时的复用。记录的复用与数据页的复用不同，记录的复用只允许对应范围的新记录复用，而如果删除整个数据页后，数据页的复用可以允许复用到任何位置。如果相邻的两个数据页的利用率都很小，系统就会把这两个页上的数据合到其中一个页上，另一个数据页就被标记为可复用。
        重建表即将原来表的记录读取出来，一行一行地插入到新表中。原来的表在删除和插入时会产生很多空洞，数据利用率不高，而重建表就可以解决这个问题。MySQL 5.6引入了 $Online\ \ DDL$ ，会先建立一个临时文件，保存原来表中的聚簇索引。在建立临时文件的过程中，在之后对原表的操作会被记录到日志文件中，并在临时文件建立完成后重新应用到临时文件中，从而允许重建表过程中的读写。
        在不同的引擎中，$COUNT(*)$ 有不同的实现方式，MyISAM把表的行数存在了磁盘上，可以直接返回；InnoDB会把数据一行一行地读出来然后计数。由于MVCC的存在，在某个时间段表有多少行是不确定的，因此InnoDB并不能简单地将行数存起来。MySQL对此的优化策略是，如果表存在多个索引，那么会选择较小的一颗索引树进行扫描。
        MySQL会给每个线程分配一块内存用于排序，称为 $sort_-buffer$。在 $sort_-buffer$ 里面的字段，会每次从数据库中取出数据并存到里面。当取出所有数据后再进行快速排序，如果内存空间不足，会使用外部排序。如果单行长度超过排序的最大长度，那么会将要排序的字段与ID关联，在排序完成后再通过ID回查。如果现有索引覆盖了需要排序的字段，那么会直接使用索引。对于使用聚集函数的排序，MySQL可能会使用临时表。临时表默认是在内存中的，如果超过了内存临时表的大小，就会转成磁盘临时表。
        内存表指的是使用Memory引擎的表，这种表的数据都保存在内存里，系统重启的时候会被清空，但是表结构还在。临时表可以使用各种引擎类型，如果是使用InnoDB或者MyISAM引擎的临时表，写数据的时候是写到磁盘上的。一个临时表只能被创建它的 $session$ 访问，可以与普通表同名。

2. 日志

        更新语句的执行过程其实与查询语句一样，但是会涉及日志模块。
        redo log记录将要修改的记录，使用了WAL ( $Write-Ahead\ \ Logging$ ) 技术，即先写日志，再写磁盘。当有一条记录需要更新时，InnoDB会先把记录写到redo log中，并更新内存，之后在适当的时候，将这个操作记录更新到磁盘中，往往是在磁盘比较空闲的时候。
        InnoDB的redo log是固定大小的，写到末尾时就循环回到开头重新写。$write\ \ pos$ 是当前记录的位置，随着数据写入后移。$check\ \ point$ 是当前要擦除的位置，在擦除之前要把记录更新到数据文件。$write\ \ pos$ 和 $check\ \ point$ 之间的部分可以记录新的操作。如果之间没有空白部分，需要等待执行记录。
        InnoDB通过redo log，可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，称为 $crash-safe$ 。
        binlog与redo log的区别有：

redo log是InnoDB特有的，binlog是MySQL的Server层实现的；
redo log是物理日志，记录对某个数据页的修改；binlog是逻辑日志，记录语句的原始逻辑；
redo log是循环写入的，binlog是可以追加写入的，即当文件达到一定空间后切换到下一个文件；
binlog的应用场景是主从复制和数据恢复；redo log记录对数据页的修改，InnoDB使用LSN ( $Log\ \ Sequence\ \ Number$ ) 进行标记，如果数据页中的LSN落后于redo log的LSN，就通过redo log恢复数据。

每当引擎将新数据更新到内存中时，就会把更新操作记录到redo log中，此时redo log处于 $prepare$ 状态。当执行器执行完成后，会生成操作的binlog。当事务提交之后，引擎会把刚写入的redo log改成 $commit$ 状态，完成更新。
写redo log的时候，可以通过 $innodb_-flush_-log_-at_-trx_-commit$ 参数设置：

CSAPP笔记

Wed, 19 May 2021 15:06:19 +0800

1. 计算机系统漫游

#include <stdio.h>

int main() {
    printf("hello, world\n");
    return 0;
}

$hello$ 程序生命周期的一开始是一个高级C程序，因为处于这种形式时，它是能够被人读懂的。为了运行 $hello.c$ ，每条C语句都必须被其他程序转化为一系列的低级机器语言指令。然后这些指令按照一种称为可执行目标程序 ( $executable\ \ object\ \ program$ ) 的格式打包，并以二进制磁盘文件的形式存放起来。在Unix系统上，从源文件到目标文件的转化是由编译器驱动程序 ( $compiler\ \ driver$ ) 完成的，这个过程可以分成四个阶段，执行这四个阶段的程序一起构成了编译系统：

预处理阶段。预处理器 ( $cpp$ ) 根据以字符 $\#$ 开头的命令 ( $directives$ )，修改原始的C程序。修改完成后得到另一个C程序，通常是以 $.i$ 作为文件扩展名；
编译阶段：编译器 ( $ccl$ ) 将文本文件 $hello.i$ 翻译成文本文件 $hello.s$ ，它包含一个汇编语言程序；
汇编阶段：汇编器 ( $as$ ) 将 $hello.s$ 翻译成机器语言指令，并把这些指令打包成一种叫做可重定位 ( $relocatable$ ) 目标程序的格式，将结果保存在目标文件 $hello.o$ 中；
链接阶段：$hello.c$ 调用了C库函数 $printf$ ，后者存在于名为 $printf.o$ 的单独的预编译目标文件中。链接器 ( $ld$ ) 负责处理目标文件的并入，处理完成后得到可执行文件。可执行文件加载到存储器后，由系统负责执行。

操作系统笔记

Mon, 10 May 2021 20:54:33 +0800

计算机操作系统概述

1. 概述

操作系统 ( $Operating\ \ System$, $OS$ ) 是指控制和管理整个计算机系统的硬件和软件资源，以提供给用户和其他软件方便的接口和环境的程序集合，是计算机系统中最基本的系统软件。没有任何软件支持的计算机称为裸机。裸机在最里层，外面是操作系统。
操作系统是计算机系统资源的管理者：

处理机管理：处理机的分配和运行以进程（或线程）为基本单位，因为对处理机的管理可以归结为对进程的管理；
存储器管理：对内存的管理；
文件管理：文件系统；
设备管理：I/O。

操作系统还提供了用户接口：

命令接口：使用命令接口进行作业控制的方式有两种：联机控制方式和脱机控制方式。进一步的，按照控制方式，可以将命令接口分为联机命令接口和脱机命令接口。
- 联机命令接口适用于分时或实时系统的接口，由一组键盘操作命令组成。用户通过控制台或者终端输入命令；
- 脱机命令接口又称批处理命令接口，适用于批处理系统，由一组作业控制命令组成，用户不能直接干预作业运行，实现用相应的作业控制命令做成一份作业操作说明书，连同作业一起提交给系统。
程序接口由一组系统调用组成，用户通过在程序中使用这些系统调用命令来请求操作系统为其提供服务。

计算机系统中，通常CPU执行两种不同性质的程序：一种是操作系统内核程序，另一种是用户自编程序或者系统外层的应用程序。对于操作系统而言，前者是后者的管理者。内核程序可以执行一些特权指令，如I/O、中断、管理程序状态字寄存器等，出于安全考虑，这些程序不能被用户直接使用。操作系统在实现上划分了核心态（管态）和用户态（目态）以严格区分两类程序。
内核是计算机上配置的底层软件，大多数操作系统的内核包括四个方面的内容：

时钟管理：时钟的第一功能是计时，通过时钟可以提供系统时间。此外，通过时钟中断，也可以实现进程切换；
中断机制：现代操作系统是靠中断驱动的软件。中断机制中，只有一小部分功能属于内核，负责保护和恢复中断现场信息，转移控制权，这样可以减少中断的处理时间；
原语 ( $Atomic\ \ Operation$ ) ：原语是一些可以被调用的小程序，处于操作系统的最底层，是最接近硬件的部分，具有原子性，且运行时间短、调用频繁；
系统控制的数据结构及处理：操作系统中存在许多记录状态信息的数据结构，如作业控制块、进程控制块、内存分配表等，操作系统需要一些对这些数据结构进行管理的基本操作。

        从上述内容可知，核心态指令包括系统调用类指令和一些针对时钟、中断和原语的操作指令。
        操作系统不允许用户程序实现核心态的功能，而它们又必须使用这些功能。因此，需要实现核心态和用户态之间的转换。在实际操作系统中，CPU运行上层程序时的唯一转换途径是通过中断或异常。当中断或异常发生时，运行用户态的CPU会立即进入核心态，这是通过硬件实现的（例如用一个特殊寄存器表示）。
        中断 ( $Interruption$ ) 指来自CPU执行指令以外的事件的发生，如设备I/O中断、时钟中断等。访管指令是一条可以在用户态下执行的指令，用于产生一个中断，称为访管中断，系统会根据访管指令的操作数执行对应的访管中断处理程序。异常 ( $Exception$ )，也称为陷入 ( $Trap$ ) ，指来自CPU执行指令内部的事件的发生，如程序的非法操作码、地址越界、内存缺页以及专门的陷入指令等。对异常的处理一般要依赖于当前程序的运行现场，并且异常不能被屏蔽，一旦出现应立即处理。
        系统调用是用户在程序中调用操作系统提供的一些子功能，可以把系统调用看作是特殊的公共子程序。在用户程序中，凡是与资源有关的操作，都必须通过系统调用向操作系统提出服务请求，并由操作系统代为完成。系统调用大致可以分为如下几类：

设备管理：设备请求、启动以及释放等；
文件管理：对文件的读写、创建和删除等；
进程控制：对进程的创建、销毁、阻塞和唤醒等；
进程通信：进程之间的消息传递；
内存管理：对内存的分配、回收以及获取内存区大小和地址等。

用户通过操作系统运行上层程序，上层程序依赖于操作系统的底层管理程序提供服务支持。当需要管理程序服务时，系统通过硬件中断机制进入核心态；当程序运行出现异常时，系统通过异常处理机制进入核心态。当管理程序结束时，用户程序继续运行，通过之前中断处理程序或者异常处理程序保存的中断现场，返回断点处继续执行。

2. 进程和线程

2.1 进程

在多道程序环境下，多个程序可以并发执行，为此引入了进程 ( $Process$ )。为了使参与并发执行的程序能够独立地执行，操作系统为之配置了一个专门的数据结构称为进程控制块 ( $Process\ \ Control\ \ Block$, $PCB$ )。系统利用PCB来描述进程的基本情况和运行状态，进而实现对进程的控制和管理。程序段、相关数据段和PCB构成了进程实体，进程实体是静态的，但是进程是动态的。进程创建实质上是创建PCB，撤销实质上是撤销PCB，PCB是进程存在的唯一标志。PCB通常包含以下内容：

Leetcode题解（7）：股票问题

Sat, 24 Apr 2021 19:11:33 +0800

I

LeetCode121.买卖股票的最佳时机

题目很简单，所以直接写了。思路就是遍历数组，维护一个最小值，以及一个最大差值。在遍历过程中不断计算差值，如果当前值比最小值小则更新最小值，如果当前差值比最大差值大则更新差值。

func maxProfit(prices []int) int {
    min, res := prices[0], 0
    for _, v := range prices {
        if v < min {
            min = v
        } else if res < v - min {
            res = v - min
        }
    }
    return res
}

II

LeetCode122.买卖股票的最佳时机II

与上一题不同的是这次可以多次购买，但是同样很简单，只要差值是正数就可以直接加在结果上。

func maxProfit(prices []int) int {
    min, res := prices[0], 0
    for _, v := range prices {
        if v < min {
            min = v
        } else {
            res += v-min
            min = v
        }
    }
    return res
}

我们可以把第二题看成维护两个状态，买入 $buy$ 和卖出 $sell$ ，从而第二题可以这样实现：

StampedLock源码解读

Tue, 30 Mar 2021 14:05:51 +0800

1. 字段

// 处理器数量
private static final int NCPU = Runtime.getRuntime().availableProcessors();
// 入队前的最大重试次数
private static final int SPINS = (NCPU > 1) ? 1 << 6 : 0;
// 作为首节点阻塞前的最大重试次数
private static final int HEAD_SPINS = (NCPU > 1) ? 1 << 10 : 0;
// 再次阻塞前的最大重试次数
private static final int MAX_HEAD_SPINS = (NCPU > 1) ? 1 << 16 : 0;
// 等待自旋上溢的闲置时期，必须为2的幂次-1
private static final int OVERFLOW_YIELD_RATE = 7;
// 在上溢前记录读锁的位数，占据低位
private static final int LG_READERS = 7;
// 每次读增加的单位
private static final long RUNIT = 1L;
// 写锁所在位数
// 1000 0000
private static final long WBIT = 1L << LG_READERS;
// 读锁所在位数
// 0111 1111
private static final long RBITS = WBIT - 1L;
// 读锁上限
// 0111 1110
private static final long RFULL = RBITS - 1L;
// 掩码
// 1111 1111
private static final long ABTIS = RBITS | WBITS;
// 读锁反数
// 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 1000 0000
private static final long SBITS = ~RBITS;
// 锁状态初始值
// 0001 0000 0000
private static final long ORIGIN = WBIT << 1;
// 取消获取锁时的特殊状态，表示中断
private static final long INTERRUPTED = 1L;
// 等待状态
private static final int WAITING = -1;
// 取消状态
private static final int CANCELLED = 1;
// 节点读模式
private static final int RMODE = 0;
// 节点写模式
private static final int WMODE = 1;
// CLH队列首节点
private transient volatile WNode whead;
// CLH队列尾节点
private transient volatile WNode wtail;
// 视图
transient ReadLockView readLockView;
transient WriteLockView writeLockView;
transient ReadWriteLockView readWriteLockView;
// 锁队列状态
// 高24位为版本号，每次获取和释放写锁都会+1，25位为写锁标志，剩余7位为读锁计数，记录当前读锁数量
private transient volatile long state;
// 额外的读锁计数
private transient int readerOverflow;

2. 内部类

// 节点在队列中排列，连续的写节点会在队列中，连续的读节点会在cowait中
// 等待节点
static final class WNode {
    volatile WNode prev;
    volatile WNode next;
    volatile WNode cowait; // 读线程所在链表
    volatile Thread thread; // 当前节点阻塞的线程
    volatile int status; // 0、WAITING或者CANCELLED
    final int mode; // RMODE或者WMODE
    WNode(int m, WNode p) { mode = m; prev = p; }
}

3. 构造函数

public StampedLock() { state = ORIGIN; }

4. 写锁

// 尝试获取独占写锁，阻塞直到成功获取
public long writeLock() {
    long s, next;
    return ((((s = state) & ABITS) == 0L && // 写锁未被获取
             // 尝试更新状态，增加一个写计数
             U.compareAndSwapLong(this, STATE, s, next = s + WBIT)) ?
             next : acquireWrite(false, 0L));
}

private long acquireWrite(boolean interruptible, long deadline) {
    WNode node = null, p;
    // 第一次自旋
    for (int spins = -1;;) {
        long m, s, ns;
        if ((m = (s = state) & ABITS) == 0L) {
            // 再次尝试获取写锁
            if (U.compareAndSwapLong(this, STATE, s, ns + WBIT))
                return ns;
        } else if (spins < 0)
            // 存在独占写锁并且队列为空，自旋
            spins = (m == WBITS && wtail == whead) ? SPINS : 0;
        else if (spins > 0) {
            // 随机减少一次自旋次数
            if (LockSupport.nextSecondarySeed() >= 0)
                --spins;
        } else if ((p = wtail) == null) { // 队列为空
            // 创建哑节点作为首节点
            WNode hd = new WNode(WMODE, null);
            if (U.compareAndSwapObject(this, WHEAD, null, hd))
                wtail = hd;
        } else if (node == null) // 队列非空，创建节点
            node = new WNode(WMODE, p);
        else if (node.prev != p) // 尾节点改变，更新尾节点
            node.prev = p;
        else if (U.compareAndSwapObject(this, WTAIL, p, node)) { // 尝试将当前节点设为尾节点，退出循环
            p.next = node;
            break;
        }
    }
    // 第二次自旋
    for (int spins = -1;;) {
        WNode h, np, pp; int ps;
        // 前驱节点为首节点
        if ((h = whead) == p) {
            if (spins < 0) // 设置自旋次数
                spins = HEAD_SPINS;
            else if (spins < MAX_HEAD_SPINS) // 增加自旋次数
                spins <<= 1;
            // 第三次自旋
            for (int k = spins;;) {
                long s, ns;
                if (((s = state) & ABITS) == 0L) {
                    // 尝试获取写锁
                    if (U.compareAndSwapLong(this, STATE, s,
                                             ns = s + WBIT)) {
                        // 获取成功，设置当前节点为首节点
                        whead = node;
                        node.prev = null;
                        return ns;
                    }
                } else if (LockSupport.nextSecondarySeed() >= 0 &&
                           --k <= 0) // 随机减少自旋次数
                    break;
            }
        } else if (h != null) { // 前驱节点非空
            WNode c; Thread w;
            // 首节点相连的读线程链表非空
            while ((c = h.cowait) != null) {
                // 唤醒读线程节点
                if (U.compareAndSwapObject(h, WCOWAIT, c, c.cowait) &&
                    (w = c.thread) != null)
                    U.unpark(w);
            }
        }
        // 首节点未改变
        if (whead == h) {
            // 前驱节点改变，更新前驱节点
            if ((np = node.prev) != p) {
                if (np != null)
                    (p = np).next = node;
            } else if ((ps = p.status) == 0)
                // 设置前驱节点为WAITING状态
                U.compareAndSwapInt(p, WSTATUS, 0, WAITING);
            else if (ps == CANCELLED) { // 前驱节点被取消
                // 删除前驱节点
                if ((pp = p.prev) != null) {
                    node.prev = pp;
                    pp.next = node;
                }
            } else {
                long time;
                if (deadline = 0L) // 未设置超时时间
                    time = 0L;
                else if ((time = deadline - System.nanoTime()) <= 0L)
                    // 超时，取消当前节点
                    return cancelWaiter(node, node, false);
                Thread wt = Thread.currentThread();
                // 记录节点阻塞的锁
                U.putObject(wt, PARKLOCKER, this);
                // 设置当前节点线程为当前线程
                node.thread = wt;
                // 前驱节点被阻塞、前驱节点非首节点或者写锁已经被获取、首节点未改变、前驱节点未改变
                if (p.status < 0 && (p != h || (state & ABITS) != 0L) &&
                    whead == h && node.prev == p)
                    // 阻塞当前线程
                    U.park(false, time);
                // 当前节点被唤醒，清除线程
                node.thread = null;
                U.putObject(wt, PARKLOCKER, null);
                // 是否检查中断，如果中断，取消当前节点
                if (interruptible && Thread.interrupted())
                    return cancelWaiter(node, node, true);
            }
        }
    }
}

总结：

Leetcode题解（6）：用Rand7实现Rand10

Fri, 26 Mar 2021 20:08:53 +0800

LeetCode470

        在解决这道题之前，我们可以先查看一个反过来的情况——用 $Rand10()$ 实现 $Rand7()$ ，可以直接发现实现方式就是不断用 $Rand10()$ 生成随机数，直到生成的数字处于 $1 \sim 7$ 之间即可。也就是说，如果可以生成的数字范围要大于待生成的数字范围，可以通过不断循环直到获取落在生成范围里面的数字的方式实现。
        利用上述思想，我们可以很容易的想出这道题的解法——利用 $Rand7()$ 构造一个生成的数字范围大于 $1 \sim 10$ 的随机数生成器即可。要想构造这样的生成器，我们可以再观察下 $Rand10()$ 。如果我们想要用 $Rand10()$ 构造一个生成数字范围在 $1 \sim 99$ 之间的随机数生成器，可以使用如下算法 $(Rand10() - 1) * 10 + Rand10()$ ，也就是生成两次，一个作为十位一个作为个位。可以很容易发现这种算法生成的数字是随机均匀分布的。
        使用 $Rand10()$ 的例子生成的是 $10$ 进制二位数，利用同样的思想我们也可以生成 $7$ 进制二位数，即 $(Rand7() - 1) * 7 + Rand7()$ ，使用这种方式生成的数字也是随机均匀分布的。将其转为 $10$ 进制后，数字范围落在 $1 \sim 49$ 之间，如果直接抛弃 $11 \sim 49$ 之间的数字，那么可能需要重复调用很多次。因此我们可以只抛弃 $41 \sim 49$ 之间的数字，对剩余的数字采用取模运算，实现方式如下：

class Solution extends SolBase {
    public int rand10() {
        int num;
        do {
            num = (rand7() - 1) * 7 + rand7();
        } while (num > 40);
        return num % 10 + 1;
    }
}

上述的实现方式是抛弃了 $41 \sim 49$ 之间的数字，抛弃了 $9$ 个数字的实现方式还是有点多的。从我们之前的讲解来看，可以不局限于生成两位数，三位数、四位数也是可以的，因此我们也可以这样实现：首先生成 $7$ 进制两位数，如果不大于 $40$ ，返回，否则利用两位数再次生成 $3$ 位数、$4$ 位数。对于 $Rand7()$ ，我们只需要生成到 $7$ 进制 $4$ 位数就行了，因为 $7^3=243$ ，$7^4=1701$ ，也就是 $4$ 位数最多只需要抛弃 $1$ 个数字，而如果是 $5$ 位数，则又要抛弃 $7$ 个数字才行。
我们也可以利用取模 $10$ 这个点来进一步简化算法。如果生成的数字在 $41 \sim 49$ 之间，没有必要直接用该数字进行计算，因为 $40$ 在取模这一步会被消掉，无论乘以哪个数字，所以我们可以将生成的数字减去 $40$ 再进行计算。减去 $40$ 后生成的数字范围在 $1 \sim 63$ 之间，同样的，如果生成了 $61 \sim 63$ 之间的数字，也可以减去 $60$ 后再计算。实现方式如下：

Redis底层数据结构实现

Thu, 25 Mar 2021 23:02:23 +0800

1. 对象

Redis中的每个键值对都是由两个对象结构表示，定义在 $server.h$ 文件中。

// 对象类型
#define OBJ_STRING 0
#define OBJ_LIST 1
#define OBJ_SET 2
#define OBJ_ZSET 3
#define OBJ_HASH 4
#define OBJ_MODULE 5
#define OBJ_STREAM 6
// 对象编码
#define OBJ_ENCODING_RAW 0 // SDS
#define OBJ_ENCODING_INT 1 // 长整型
#define OBJ_ENCODING_HT 2 // 字典
#define OBJ_ENCODING_ZIPMAP 3
#define OBJ_ENCODING_LINKEDLIST 4
#define OBJ_ENCODING_ZIPLIST 5 // 压缩列表
#define OBJ_ENCODING_INTSET 6 // 整数集合
#define OBJ_ENCODING_SKIPLIST 7 // 跳表
#define OBJ_ENCODING_EMBSTR 8 // embstr编码的SDS
#define OBJ_ENCODING_QUICKLIST 9
#define OBJ_ENCODING_STREAM 10
// 对象结构
typedef struct redisObject {
    unsigned type:4; // 类型
    unsigned encoding:4; // 编码
    unsigned lru:LRU_BITS; // 最后一次访问时间
    int refcount; // 引用计数
    void *ptr; // 底层指针
} robj;

1. `SDS`

简单动态字符串 ( $simple\ \ dynamic\ \ string$, $SDS$ ) 是Redis中字符串的数据结构，定义在 $sds.h$ 头文件中。

ReentranLock源码解读

Sat, 20 Mar 2021 22:27:10 +0800

$ReentrantLock$ 是一个可重入的独占锁，与 $synchronized$ 行为类似，但提供了额外的功能。

1. 构造函数

// 默认为非公平锁
public ReentrantLock() { sync = new NonfairSync(); }

public ReentrantLock(boolean fair) { sync = fair ? new FairSync() : new NonfairSync(); }

2. 内部类

abstract static class Sync extends AbstractQueuedSynchronizer {
    private static final long serialVersionUID = -5179523762034025860L;

    abstract void lock();

    // 非公平上锁, tryAcquire方法在子类中实现
    final boolean nonfairTryAcquire(int acquires) {
        final Thread current = Thread.currentThread();
        int c = getState();
        if (c == 0) { // 锁未被占有
            if (compareAndSetState(0, acquires)) { // 尝试获取锁
                setExclusiveOwnerThread(current); // 设置独占线程
                return true;
            }
        }
        else if (current == getExclusiveOwnerThread()) { // 当前线程已经占有锁
            int nextc = c + acquires;
            if (nextc < 0)
                throw new Error("Maximum lock count exceeded");
            setState(nextc); // 添加上锁次数
            return true;
        }
        return false;
    }

    protected final boolean tryRelease(int releases) {
        int c = getState() - releases;
        if (Thread.currentThread() != getExclusiveOwnerThread()) // 当前线程非独占线程
            throw new IllegalMonitorStateException();
        boolean free = false;
        if (c == 0) { // 锁被释放
            free = true;
            setExclusiveOwnerThread(null); // 取消独占状态
        }
        setState(c);
        return free;
    }

    // 当前实现是否持有锁
    protected final boolean isHeldExclusively() {
        return getExclusiveOwnerThread() == Thread.currentThread();
    }

    final ConditionObject newCondition() {
        return new ConditionObject();
    }

    // 返回持有者线程
    final Thread getOwner() { return getState() == 0 ? null : getExclusiveOwnerThread(); }

    // 返回当前线程上锁次数
    final int getHoldCount() { return isHeldExclusively() ? getState() : 0; }

    final boolean isLocked() { return getState() != 0; }

    private void readObject(java.io.ObjectInputStream s) { /* 省略 */ }
}

// 非公平锁
static final class NonfairSync extends Sync {
    private static final long serialVersionUID = 7316153563782823691L;

    final void lock() {
        if (compareAndSetState(0, 1)) // 尝试上锁
            setExclusiveOwnerThread(Thread.currentThread());
        else // 自旋获取锁
            acquire(1);
    }

    protected final boolean tryAcquire(int acquires) { return nonfairTryAcquire(acquires);} // 调用父类方法
}

// 公平锁
static final class FairSync extends Sync {
    private static final long serialVersionUID = -3000897897090466540L;

    final void lock() { acquire(1); } // 公平方式获取锁，获取失败则自旋

    // 公平方式获取锁
    protected final boolean tryAcquire(int acquires) {
        final Thread current = Thread.currentThread();
        int c = getState();
        if (c == 0) {
            if (!hasQueuedPredecessors() && // 没有前驱节点
                compareAndSetState(0, acquires)) { // 尝试获取锁
                setExclusiveOwnerThread(current);
                return true;
            }
        }
        else if (current == getExclusiveOwnerThread()) { // 当前线程为独占线程
            int nextc = c + acquires; // 添加获取次数
            if (nextc < 0)
                throw new Error("Maximum lock count exceeded");
            setState(nextc);
            return true;
        }
        return false;
    }
}

其中 $acquire$ 方法的实现可以在这里查看。

AQS源码解读

Fri, 19 Mar 2021 20:14:24 +0800

AQS提供了一个实现阻塞锁和相关的基于FIFO队列的同步器的框架。该类作为大部分依赖于一个状态字段的同步器的基础。子类必须定义 $protected$ 方法来改变状态，其他方法用于管理队列和实现阻塞机制。子类也可以包含其他状态字段，但必须通过原子性操作维护状态。

1. 成员变量

// 等待队列的头节点，懒加载，只能通过setHead方法修改
private transient volatile Node head;
// 等待队列的尾部，懒加载，只能通过enq方法添加新节点
private transient volatile Node tail;
// 同步状态
private volatile int state;
// 如果超时时间大于该值，中断，单位为纳秒
static final long spinForTimeoutThreshold = 1000L;

2. 内部类`Node`

static final class Node {
    // 节点在共享模式等待的标志
    static final Node SHARED = new Node();
    // 节点在独占模式等待的标志
    static final Node EXCLUSIVE = null;
    // 表示线程被取消
    static final int CANCELLED = 1;
    // 表示线程在释放资源后需要唤醒后继节点
    static final int SIGNAL = -1;
    // 表示线程在等待condition
    static final int CONDITION = -2;
    // 共享模式下表示无条件传播
    static final int PROPAGATE = -3;
    // 等待状态
    volatile int waitStatus;
    // 前驱节点
    volatile Node prev;
    // 后继节点
    volatile Node next;
    // 节点对应的线程
    volatile Thread thread;
    // 下一个在condition上等待的节点，或者表示共享模式
    Node nextWaiter;

    final boolean isShared() { return nextWaiter == SHARED; }

    final Node predecessor() throws NullPointerException {
        Node p = prev;
        if (p == null)
            throw new NullPointerException();
        else
            return p;
    }

    Node() {} // 用于创建头节点或者共享标记

    Node(Thread thread, Node mode) {
        this.nextWaiter = mode;
        this.thread = thread;
    }

    Node(Thread thread, int waitStatus) {
        this.waitStatus = waitStatus;
        this.thread = thread;
    }
}

3. 获取锁

3.1 独占模式

// 独占模式获取资源，忽略中断，未获取成功则阻塞
public final void acquire(int arg) {
    if (!tryAcquire(arg) &&
        acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
        selfInterrupt();
}

// 尝试以独占模式获取锁，需要在子类中重写
protected boolean tryAcquire(int arg) {
    throw new UnsupportedOperationException();
}

// 根据给定模式创建队列节点
private Node addWaiter(Node mode) {
    Node node = new Node(Thread.currentThread(), mode);
    Node pred = tail;
    if (pred != null) {
        node.prev = pred;
        if (compareAndSetTail(pred, node)) { // 如果在此入队成功，直接返回
            pred.next = node;
            return node;
        }
    }
    enq(node); // 入队失败，循环直到成功
    return node;
}

// 节点入队
private Node enq(final Node node) {
    for(;;) {
        Node t = tail;
        if (t == null) {
            if (compareAndSetHead(new Node())) // 队列为空，设置哑节点
                tail = head;
        } else {
            node.prev = t;
            if (compareAndSetTail(t, node)) {
                t.next = node;
                return t;
            }
        }
    }
}

// 自旋获取锁
final boolean acquireQueued(final Node node, int arg) {
    boolean failed = true;
    try {
        boolean interrupted = false;
        for (;;) {
            final Node p = node.predecessor(); // 获取前驱节点
            if (p == head && tryAcquire(arg)) { // 如果没有前驱节点在等待，尝试获取锁
                setHead(node);
                p.next = null; // 帮助GC
                failed = false;
                return interrupted;
            }
            if (shouldParkAfterFailedAcquire(p, node) && // 根据状态判断是否阻塞
                parkAndCheckInterrupt())
                interrupted = true;
        }
    } finally {
        if (failed)
            cancelAcquire(node);
    }
}

// 检查和更新获取锁失败的节点状态，true表示需要阻塞
private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
    int ws = pred.waitStatus; // 获取前驱节点状态
    if (ws == Node.SIGNAL) // SIGNAL状态下前驱节点释放资源后会通知后继节点，因而可以阻塞
        return true;
    if (ws > 0) { // 前驱节点被取消
        do {
            node.prev = pred = pred.prev;
        } while (pred.waitStatus > 0); // 寻找最近的一个处于正常状态的节点
        pred.next = node;
    } else { // 其他状态则设置前驱节点为SIGNAL，令其在释放资源后通知自己
        compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
    }
    return false;
}

// 挂起当前线程
private final boolean parkAndCheckInterrupt() {
    LockSupport.park(this);
    return Thread.interrupted();
}

// 产生一个中断
static void selfInterrupt() {
    Thread.currentThread().interrupt();
}

总结一下 $acquire$ 方法的执行步骤：

Leetcode题解（5）：LRU与LinkedHashMap

Tue, 16 Mar 2021 18:05:19 +0800

LeetCode146

为了记录访问顺序，我们可以使用一个双向链表，首节点为最近最少访问的数据，尾节点为最近访问的数据。为了快速获取值，我们可以额外使用一个 $Map$ 存储键值映射。

public class LRUCache {
    private int capacity;
    private int size;
    private Map<Integer, Node> map;
    private Node head;
    private Node tail;

    public LRUCache(int capacity) {
        this.capacity = capacity;
        size = 0;
        map = new HashMap<>();
    }

    public int get(int key) {
        Node node = getNode(key);
        return node == null ? -1 : node.val;
    }

    public void put(int key, int value) {
        Node node = getNode(key);
        if (node != null) {
            node.val = value;
            return;
        }
        if (++size > capacity) removeHead();
        node = new Node(key, value);
        putToTail(node);
        map.put(key, node);
    }

    private Node getNode(int key) {
        Node node = map.get(key);
        if (node == null) return null;
        putToTail(node);
        return node;
    }

    private void removeHead() {
        map.remove(head.key);
        if (head == tail) head = tail = null;
        else {
            head = head.next;
            head.prev = null;
        }
        --size;
    }

    private void putToTail(Node node) {
        if (head == null) {
            head = tail = node;
            return;
        } else if (node == tail)
            return;
        if (head == node) head = head.next;
        Node p = node.prev, n = node.next;
        if (n != null) n.prev = p;
        if (p != null) p.next = n;
        tail.next = node;
        node.prev = tail;
        node.next = null;
        tail = node;
    }

    private class Node {
        int key;
        int val;
        Node prev;
        Node next;

        public Node(int key, int val) {
            this.key = key;
            this.val = val;
        }
    }
}

讲完了 $LRUCache$ 之后就可以讲讲 $LRUCache$ 与 $LinkedHashMap$ 之间的关系了。默认情况下 $LinkedHashMap$ 是一种保存了值写入顺序的 $HashMap$ ，扩展了 $HashMap$ ，也就是说底层与 $HashMap$ 相同。而写入顺序是通过一个双向链表存储的，在每次写入和删除时更新。
可以发现 $LinkedHashMap$ 里面有一个特殊的构造函数：

Leetcode题解（4）：字符串相加

Tue, 16 Mar 2021 15:50:38 +0800

LeetCode415

题目挺简单的，也没有什么难点和要注意的点，正常写就行了。

public class Solution {
    public String addStrings(String num1, String num2) {
        int n1 = num1.length() - 1, n2 = num2.length() - 1, carry = 0;
        StringBuilder sb = new StringBuilder();
        while (n1 >= 0 || n2 >= 0 || carry != 0) {
            int a = n1 >= 0 ? num1.charAt(n1) - '0' : 0;
            int b = n2 >= 0 ? num2.charAt(n2) - '0' : 0;
            int sum = a + b+ carry;
            carry = sum / 10;
            sb.append((char) (sum % 10 + '0'));
            n1--;
            n2--;
        }
        return sb.reverse().toString();
    }
}

当然只有上面一道题是没有什么可讲的，重要的是上面的题的扩展，实现 $36$ 进制的加法：

Leetcode题解（3）：接雨水

Sun, 14 Mar 2021 17:49:16 +0800

LeetCode42
参考题解

1. 动态规划

对于任意一个条形块 $height[i]$ ，能蓄水的必要条件是存在 $i > l > 0$ ，$i< r < n$ 使得 $height[l] > height[i]$ 并且 $height[r] > height[i]$ 。当上述条件成立时，这个条形块的蓄水量就等于 $min(height[l],\ height[r]) - height[i]$ 。所以我们可以记录每个条形块对应的左右两边最高的条形块，然后每次遍历时比较左右两边的最高条形块，并取其中较小者。

class Solution {
    public int trap(int[] height) {
        int n = height.length;
        if (n == 0) return 0;
        int[] left = new int[n];
        int[] right = new int[n];
        left[0] = height[0];
        right[n - 1] = height[n - 1];
        for (int i = 1; i < n; i++)
            left[i] = Integer.max(height[i], left[i - 1]);
        for (int i = n - 2; i >= 0; i--)
            right[i] = Integer.max(height[i], right[i + 1]);
        int res = 0;
        for (int i = 1; i < n - 1; i++)
            res += (Integer.min(left[i], right[i])) - height[i];
        return res;
    }
}

2. 双指针

观察上面的 $left[\ ]$ 和 $right[\ ]$ ，可以发现它们元素的状态仅依赖于其左边或者右边元素的状态以及 $height[\ ]$ ，我们可以利用这个特性，将数组优化掉。
对于每个 $i$ ，只要 $left[i] > height[i]$ ，$right[i] > height[i]$ ，并且 $left[i] < right[i]$ ，那么就由左边条形柱决定蓄水量，否则就由右边决定。也就是说，对于每个 $height[i]$ ，只要其左右两边存在 $left_-max > height[i]$ 并且 $right_-max > height[i]$ 即可蓄水。所以我们可以记录一个 $left_-max$ 和一个 $right_-max$ ，然后利用双指针遍历更新。指针移动规则是：

String.indexOf方法和KMP算法简介

Sat, 13 Mar 2021 21:14:45 +0800

1. `String.indexOf`

子字符串查找是字符串的一种基本操作：给定一段长度为 $N$ 的文本和一个长度为 $M$ 的模式 ( $pattern$ ) 字符串，在文本中找到一个和该模式相符的子字符串。对于一般的暴力式方法，在最坏的情况下运行时间与 $MN$ 成正比，但是在处理许多应用程序中的字符串时 ( 除了一些极端情况外 )，它的实际运行时间一般与 $M + N$ 成正比。另外，它很好地利用了大多数计算机系统中标准的结构特性，因此即使是更加巧妙的算法也很难超越它经过优化后的版本的性能。

public static int search(String pat, String txt) {
    int M = pat.length();
    int N = txt.length();
    for (int i = 0; i <= N; i++) {
        int j;
        for (j = 0; j < M; j++)
            if (txt.charAt(i + j) != pat.charAt(j))
                break;
        if (j == M) return i;
    }
    return N;
}

$String.indexOf$ 提供了子字符串查找功能，实现方式也是类似于上面的暴力式方法：

TCP、UDP和DNS简介

Sat, 06 Mar 2021 15:36:09 +0800

1. `TCP`

        TCP是一种面向连接的 ( $connection-oriented$ ) 协议，在一个应用进程向另一个应用进程发送数据之前，这两个进程必须先相互握手。TCP建立的连接是一条逻辑链接，其共同状态仅保留在两个通信端系统的TCP程序中。由于TCP协议只在端系统中运行，而不在中间的网络元素（路由器和链路层交换机）中运行，所以中间的网络元素不会维持TCP连接状态。事实上，中间路由器看到的是数据报，而非TCP连接。
        一旦建立起一条TCP连接，两个应用进程之间就可以相互发送数据了。TCP接收到数据后，会将数据引导到连接的发送缓存 ( $send\ \ buffer$ ) 里，发送缓存是发起三次握手期间设置的缓存之一。接下来TCP就会时不时从发送缓存里取出一块数据，并将数据传递到网络层。TCP可从缓存中取出并放入报文段中的数据数量受限于最大报文段长度 ( $Maximum\ \ Segment\ \ Size$ ，$MSS$ )。MSS通常根据最初确定的由本地发送主机发送的最大链路层帧长度( 即所谓的最大传输单元 ( $Maximum\ \ Transmission\ \ Unit$ ，$MTU$ )) 来设置。以太网和PPP链路层协议都具有 $1500$ 字节的MTU，再加上TCP/IP首部长度 ( 通常为 $40$ 字节 ) ，因此MSS的典型值为 $1460$ 字节。
        TCP为每块客户端数据配上一个TCP首部，从而形成多个TCP报文段 ( $TCP\ \ segment$ )。这些报文段被下传给网络层，网络层将其分别封装在网络层IP数据报中。然后这些IP数据报被发送到网络中。当TCP在另一端接收到一个报文段之后，该报文段的数据就被放入该TCP连接的接收缓存中。

1.1 序号和确认号

        TCP报文段首部中两个最重要的字段是序号字段和确认号字段。TCP把数据看成一个无结构的、有序的字节流。序号是建立在传送的字节流之上，而不是建立在传送的报文段的序列之上。一个报文段的序号 ( $sequence\ \ number\ \ for\ \ a\ \ segment$ ) 是该报文段首字节的字节流编号。
        TCP是全双工协议，因此主机 $A$ 在向主机 $B$ 发送数据的同时，也许也接收来自主机 $B$ 的数据。从主机 $B$ 到达的每个报文段中都有一个序号用于从 $B$ 流向 $A$ 的数据。主机 $A$ 填充进报文段的确认号是主机 $A$ 期望从主机 $B$ 收到的下一字节的序号。假设主机 $A$ 已收到一个来自主机 $B$ 的包含字节 $0 \sim 535$ 的报文段，以及另一个包含字节 $900 \sim 1000$ 的报文段。由于某种原因，主机 $A$ 还没有收到字节 $536 \sim 899$ 的报文段。在这个例子中，主机 $A$ 为了重新构建主机 $B$ 的数据流，仍在等待字节 $536$ 。因此 $A$ 到 $B$ 的下一个报文段将在确认号字段中包含 $536$ 。因为TCP只确认该流中至第一个丢失字节为止的字节，所以TCP被称为提供累计确认 ( $cumulative\ \ acknowledge$ )。当主机 $A$ 在收到第二个报文段 ( $536 \sim 899$ ) 之前收到第三个报文段 ( $900 \sim 1000$ )，这时候的处理方式TCP RFC并没有明确规定任何规则，编程人员有两种处理方式：丢弃或者缓存。显然，后一种选择对网络带宽而言更为有效，也是实践中采用的方法。
        主机 $A$ 和主机 $B$ 之间数据的确认可以承载在数据的报文段中，而不需要重新发一个独立的确认报文段，这种确认称为捎带 ( $piggybacked$ )。主机之间也可以发送空报文段，通常用于确认已经收到数据。对于空报文段，虽然没有数据，但仍然需要分配一个序号，因为TCP中存在序号字段，报文段需要填入序号。

HTTP协议介绍

Fri, 05 Mar 2021 22:19:56 +0800

1. `HTTP`

HTTP协议用于客户端和服务端之间的通信，通过请求和响应的交换达成通信。HTTP本身是一种不保存状态的协议，即无状态协议，每当有新请求发送，就会对应着有响应的产生。
请求报文和响应报文的首部内容由以下数据组成：

请求行：包含请求方法、请求URI和HTTP版本；
状态行：包含表明响应结果的状态码、原因短语和HTTP版本；
首部字段：包含表示请求和响应的各种条件和属性的各类首部，一般有四类首部：通用首部、请求首部、响应首部和实体首部；
其他：可能包含HTTP的RFC里未定义的首部 ( 如Cookie等 )。

        HTTP在传输数据时可以那招数据原貌直接传输，也可以在传输的过程中通过编码提升传输速率。报文 ( $message$ ) 是HTTP通信中的基本单位，由字节流组成；实体 ( $entity$ ) 是请求或响应的有效载荷数据，由实体首部和实体主体组成。通常报文主体等于实体主体，只有当传输中进行编码操作时，实体主体的内容才会发生变化。
        在传输大容量数据时，HTTP允许将数据分割，这种功能称为分块传输编码 ( $Chunked\ \ Transfer\ \ Coding$ )，允许将实体主体分块，每块使用十六进制标记大小，最后一块会使用 $0(CR+LF)$ 标记。为了发送多种类型实体，HTTP还采用了多部份对象集合，包含如下对象：$multipart/form-data$ 、$multipart/byteranges$ 。在使用时，需要在首部字段里加上 $Content-type$ 。
        HTTP通信时，除客户端和服务器以外，还有一些用于通信数据转发的应用程序，例如代理、网关和隧道。

代理：代理扮演了位于服务器和客户端的中间人的角色，接收请求和响应并进行转发。使用代理的理由有：利用缓存技术减少网络带宽流量，组织内部针对特定网站的访问控制，以获取访问日志为主要目的等；
网关是转发其他服务器通信数据的服务器，接收从客户端发送来的请求时，就像自己拥有资源的服务器一样处理。使用网关能提高通信的安全性；
隧道是在相隔甚远的客户端和服务器之间进行中转，并保持双方通信连接的应用程序。隧道的目的是确保客户端能与服务器进行安全的通信。

1.1 请求

GET /index.htm HTTP/1.1
Host: xxxx.com

起始行开头的 $GET$ 表示请求访问服务器的类型，称为方法。$/index.htm$ 是请求访问的资源对象，也叫做请求URI ( $Request\ \ URI$ ) 。最后的 $HTTP/1.1$ 即HTTP版本号，指明客户端使用的HTTP协议版本。
HTTP使用URI定位互联网上的资源，可以指定完整路径，也可以通过与 $Host$ 字段结合指定相对路径。如果不是访问特定资源而是对服务器本身发起请求，可以使用 $*$ 代替请求URI，如下：

OPTIONS * HTTP/1.1

HTTP/1.1中可使用的方法如下：

$GET$ ：请求访问已被URI识别的资源，经服务器段解析后返回响应内容；
$POST$ ：请求访问已被URI识别的资源，数据被包含在请求体中，可能会导致新资源的创建和修改；
$PUT$ ：传输文件，要求在请求报文主体中包含文件内容；
$HEAD$ ：与 $GET$ 一样，但不返回主体，只返回首部，用于确认URI有效性及资源更新的时间等；
$DELETE$ ：删除文件；
$OPTIONS$ ：查询针对请求URI指定的资源的支持方法；
$TRACE$ ：让Web服务器端将之前的请求通信环返回给客户端；
$CONNECT$ ：在与代理服务器通信时建立隧道，通过隧道协议进行TCP通信，主要使用SSL ( $Secure\ \ Sockets\ \ Layer$ ，安全套接层 ) 和 TLS ( $Transfer\ \ Layer\ \ Security$ ，传输层安全 ) 协议把通信内容加密后经网络隧道传输。

HTTP/1.1中提供了持久连接 ( $HTTP\ \ Persistence\ \ Connections$ ，也称为 $HTTP\ \ keep-alive$ )，只要任意一端没有明确提出断开连接，则保持TCP连接状态。持久连接使得多数请求以管道化 ( $pipelining$ ) 方式发送称为可能，即不用等待上一个请求的响应即可发送下一个请求。
作为无状态协议，在登录等场景需要保存状态，因此引入了Cookie技术。Cookie通过在请求和响应报文中写入Cookie信息来控制客户端状态。根据从服务端发送的响应报文内一个叫做 $Set-Cookie$ 的首部字段信息，客户端会保存Cookie，并在下次发送请求时自动在报文中加入Cookie。

MySQL索引介绍

Thu, 04 Mar 2021 22:16:20 +0800

索引 ( 在MySQL中也叫做键 ( $key$ )) 是存储引擎用于快速找到记录的一种数据结构。索引优化是查询性能优化最有效的手段。

1. 基础

MySQL中，索引引擎首先在索引中找到对应值，然后根据匹配的索引记录找到对应的数据行。索引可以包含一个或多个列的值。如果索引包含多个列，那么列的顺序也十分重要，因为MySQL只能高效地使用索引的最左前缀列。

1.1 类型

索引有很多类型。在MySQL中，索引是在存储引擎层而不是服务层实现的，所以并没有统一的索引标准。

1.1.1 `B-Tree`

        如果没有特别指明类型，那么通常所说的索引都是B-Tree索引，顾名思义，即使用B-Tree数据结构来存储数据。大多数MySQL引擎都支持这种索引。不过，底层的存储引擎也可能使用不同的存储结构，例如InnoDB使用的是B+Tree。存储引擎以不同的方式使用B-Tree索引，性能也各有不同，各有优劣。例如，MyISAM使用前缀压缩技术使得索引更小，但InnoDB则按照原数据格式进行存储。再如MyISAM索引通过数据的物理位置引用被索引的行，而InnoDB则根据主键引用被索引的行。
        B-Tree通常意味着所有的值都是按顺序存储的，并且每一个叶子页到根的距离相同。B-Tree索引能够加快访问数据的速度，因为存储引擎不再需要进行全表扫描来获取需要的数据，取而代之的是从索引的根节点开始进行搜索。叶子节点比较特别，它们的指针指向的是被索引的数据，而不是其他的节点页。
        B-Tree索引适用于全键值、键值范围或键值前缀查找。其中键值前缀查找只适用于根据最左前缀的查找。上述的索引对如下类型的查询有效：

全值匹配
匹配最左前缀
匹配列前缀
匹配范围值
精确匹配某一列并范围匹配另外一列
只访问索引的查询

因为索引树的节点是有序的，所以除了按值查找外，索引还可以用于查询中的 $ORDER\ \ BY$ 操作。一般来说，如果B-Tree可以按照某种方式查找到值，那么也可以按照这种方式用于排序。

1.2 哈希索引

        哈希索引 ( $hash\ \ index$ ) 基于哈希表实现，只有精确匹配索引所有列的查询才有效。对于每一行数据，存储引擎都会对所有的索引列计算一个哈希码，并存储在索引中，同时在哈希表中保存指向每个数据行的指针。在MySQL中，只有Memory引擎显式支持哈希索引，同时也是默认索引类型。如果多个列的哈希值相同，索引会以链表的方式存放多个记录指针到同一个哈希条目中。
        InnoDB引擎有一个特殊的功能叫做自适应哈希索引 ( $adaptive\ \ hash\ \ index$ )。当InnoDB注意到某些索引值被使用得非常频繁时，它会在内存中基于B-Tree索引之上再创建一个哈希索引。
        如果存储引擎不支持哈希索引，可以模拟创建哈希索引，即增加一列，存储哈希值。MySQL提供了 $CRC32$ 函数用于计算哈希值，通过设置触发器，可以在每次插入时自动插入索引。不要使用 $SHA1$ 和 $MD5$ 作为哈希函数，因为这两个函数计算出来的哈希值是非常长的字符串。如果数据表非常大，$CRC32$ 会出现大量哈希冲突，这时也可以考虑自己实现哈希函数。

2. 优点

索引可以让服务器快速地定位到表的指定位置，但并非唯一作用。最常见的B-Tree索引，按照顺序存储数据，可以用于 $ORDER\ \ BY$ 和 $GROUP\ \ BY$ 操作。利用数据有序的特点，索引有如下三个优点：

减少了服务器需要扫描的数据量；
帮助服务器避免排序和临时表；
将随机I/O变为顺序I/O。

但是索引并不总是最好的工具。对于非常小的表，大部分情况下简单的全表扫描更加高效。而对于中大型表，索引就非常有效。但对于特大型表，建立和使用索引的代价将随之增长，这时候就需要一种可以直接区分出查询需要的数据的技术，例如分区技术。

3. 索引策略

3.1 独立的列

如果查询中的列不是独立的，MySQL就不会使用索引。独立的列是指索引列不能是表达式的一部分，也不能是函数的参数。例如：

MySQL架构介绍

Thu, 04 Mar 2021 22:16:10 +0800

1. `MySQL`逻辑架构

最上层服务并不是MySQL独有，大多数基于网络的客户端/服务器的工具或者服务都有类似的架构，比如连接处理、授权认证、安全等；
第二层架构是MySQL比较有意思的部分。大多数MySQL的核心服务功能都在这一层，包括查询解析、分析、优化、缓存以及所有的内置函数（例如，日期、时间、数学和加密函数），所有跨存储引擎的功能都在这一层实现：存储过程、触发器、视图等；
第三层包含了存储引擎。存储引擎负责MySQL中数据的存储和提取。存储引擎多种多样，服务器通过API与存储引擎进行通信。这些接口屏蔽了不同存储引擎之间的差异，使得这些差异对上层的查询过程透明。存储引擎API包含了几十个底层函数，用于执行诸如“开始一个事务”或者“根据主键提取一行记录”等操作。但存储引擎不会去解析SQL ( InnoDB会解析外键定义 ) ，不同存储引擎之间也不会相互通信，而只是简单地响应上层服务器的请求。

1.1 连接管理与安全性

每个客户端连接都会在服务器进程中拥有一个线程，这个连接的查询只会在这个单独的线程中执行，该线程只能轮流在某个CPU核心或者CPU中运行。服务器会负责缓存线程，因此不需要为每一个新建的连接创建或者销毁线程。在连接建立后，服务器会验证客户端是否具有执行某个特定查询的权限。

1.2 优化与执行

MySQL会解析查询，并创建内部数据结构（解析树），然后对其进行各种优化，包括重写查询、决定表的读取顺序，以及选择合适的索引等。用户可以通过特殊的关键字提示优化器，影响它的决策过程。也可以请求优化器解释优化过程的各个因素，使用户可以知道服务器是如何进行优化决策的，并提供一个参考基准。
对于 $SELECT$ 语句，在解析查询之前，服务器会先检查查询缓存 ( $Query\ \ Cache$ )，如果能够在其中找到对应的查询，服务器就不必再执行查询解析、优化和执行的整个过程，而是直接返回查询缓存中的结果集。

2. 并发控制

在实际的数据库系统中，每时每刻都在发生锁定，当某个用户在修改某一部分数据时，MySQL会通过锁定防止其他用户读取统一数据。大多数时候，MySQL的内部管理都是透明的。
所谓的锁策略，就是在锁的开销和数据的安全性之间寻求平衡，这种平衡当然也会影响到性能。大多数商业数据库系统没有提供更多的选择，一般都是在表上施加行级锁 ( $row-level\ \ lock$ )，并以各种复杂的方式来实现，以便在锁比较多的情况下尽可能地提供更好的性能。而MySQL则提供了多种选择。每种MySQL存储引擎都可以实现自己的锁策略和锁粒度。在存储引擎的设计中，锁管理是个非常重要的决定。将锁粒度固定在某个级别，可以为某些特定的应用场景提供更好的性能，但同时却会失去对另外一些应用场景的良好支持。好在MySQL支持多个存储引擎的架构，所以不需要单一的通用解决方案。

表锁 ( $table\ \ lock$ )：表锁是MySQL中最基本的锁策略，并且是开销最小的策略，它会锁定整张表。一个用户在对表进行写操作（插入、删除、更新等）前，需要先获得写锁，这会阻塞其他用户对该表的所有读写操作。只有没有写锁时，其他的读取的用户才能获得读锁，读锁之间是不相互阻塞的。尽管存储引擎可以管理自己的锁，但MySQL本身还是会使用各种有效的表锁来实现不同的目的。例如，服务器会为诸如 $ALTER\ \ TABLE$ 之类的语句使用表锁，而忽略存储引擎锁机制；
行级锁 ( $row\ \ lock$ )：行级锁可以最大程度地支持并发处理（同时也带来了最大的锁开销）。众所周知，在InnoDB和XtraDB，以及其他一些存储引擎中实现了行级锁。行级锁只在存储引擎层实现，而MySQL服务器层没有实现。

3. 事务

事务就是一组原子性的SQL查询，或者说一个独立的工作单元。如果数据库引擎能够成功地对数据库应用该组查询的全部语句，那么就执行该组查询。

原子性 ( $atomicity$ )：一个事务必须被视为一个不可分割的最小工作单元；
一致性 ( $consistency$ )：数据库总是从一个一致性的状态转换到另外一个一致性的状态；
隔离性 ( $isolation$ )：一个事务所做的修改在最终提交以前，对其他事务是不可见的；
持久性 ( $durability$ )：一旦事务提交，其所做的修改就会永久保存到数据库中。

一个运行良好的事务处理系统，必须满足ACID特性。但在应用逻辑中，要想实现这一点很困难，甚至可以说是不可能完成的任务。一个兼容ACID的数据库系统，需要做很多复杂但可能用户并没有觉察到的工作。

3.1 隔离级别

READ UNCOMMITTED ( 未提交读 )：事务中的修改，即使没有提交，对其他事务也都是可见的。事务读取未提交的数据称为脏读 ( $Dirty\ \ Read$ )；
READ COMMITTED ( 提交读 )：大多数数据库系统的默认隔离级别都是提交读，但MySQL不是。一个事务开始时，只能看到已经提交的事务所做的修改。这个级别有时候也叫做不可重复读 ( $nonrepeatable\ \ read$ )，因为两次执行同样的查询，可能会得到不一样的结果；
REPEATABLE READ ( 可重复读 )：该级别解决了脏读问题，保证了在同一个事务中多次读取同样记录的结果是一致的。但是理论上，还是无法解决幻读 ( $Phantom\ \ Read$ ) 问题。幻读指的是当某个事物在读取某个范围内的记录时，另外一个事务又在该范围内插入了新的记录。可重复读是MySQL的默认事务隔离级别；
SERIALIZABLE ( 可串行化 )：通过强制事务串行执行，可以避免幻读问题。但是由于会在读取的每一行数据上都加锁，所以可能导致大量的超时和锁竞争问题。

3.2 死锁

为了解决死锁问题，数据库系统实现了各种死锁检测和死锁超时机制。越复杂的系统，比如InnoDB存储引擎，越能检测到死锁的循环依赖，并立即返回一个错误。还有一种解决方式，就是当查询的时间达到等待超时的设定后放弃锁请求，这种方式通常来说不太好。InnoDB目前处理死锁的方法是，将持有最少行级排他锁的事务进行回滚。
锁的行为和顺序是和存储引擎相关的。以同样的顺序执行语句，有些存储引擎会产生死锁，有些则不会。死锁的产生有双重原因：有些是因为真正的数据冲突，这种情况通常很难避免，但有些完全是由于存储引擎的实现方式导致的。

Java 8实战：日期和时间API

Thu, 18 Feb 2021 18:39:00 +0800

在Java 1.0中，对日期和时间的支持只能依赖 $java.util.Date$ 类。这个类无法表示日期，只能以毫秒的精度表示时间。而且由于某些原因未知的设计决策，这个类的易用性也不高。例如一个表示 $2014$ 年 $3$ 月 $18$ 日的 $Date$ 需要用以下方式创建：

Date date = new Date(114, 2, 18);

此外，$Date.toString$ 方法的返回值中虽然包含时区，但 $Date$ 并不支持时区。所以，在Java 1.1中，$Date$ 的许多方法被废弃，取而代之的是 $java.util.Calendar$ 类，但是这个类同样也存在着很多问题。比如月份依旧是从 $0$ 开始，而且没有提供 $DateFormat$ 方法。如果使用 $DateFormat$ 方法，那么又会带来并发问题，因为它不是线程安全的。为了解决上述问题，Java 8中新增的 $java.time$ 包中添加了新的日期和时间API。
$java.time$ 包中提供了一些新类：$LocalDate$ 、$LocalTime$ 、$Instant$ 、$Duration$ 和 $Period$ 。

1. `LocalDate`/`LocalTime`/`LocalDateTime`

$LocalDate$ 的实例是一个不可变对象，它只提供了简单的日期，并不包含当天的时间信息。另外，它也不附带任何与时区相关的信息。可以通过静态工厂方法 $of$ 创建一个 $LocalDate$ 实例，或者通过 $now$ 方法从系统时钟中获取当前日期，并通过 $getYear$ 、$getMonth$ 、$getDayOfMonth$ 等方法读取常用值。

LocalDate date = LocalDate.of(2014, 3, 18); // 2014-03-18
int year = date.getYear(); // 2014
Month month = date.getMonth(); // MARCH
int day = date.getDayOfMonth(); // 18
DayOfWeek dow = date.getDayOfWeek(); // TUESDAY
int len = date.lengthOfMonth(); // 31
boolean leap = date.isLeapYear(); // false
LocalDate today = LocalDate.now();

$TemporalField$ 是一个接口，定义了如何访问 $temporal$ 对象某个字段的值。$ChronoField$ 枚举实现了这一接口，通过 $get$ 方法可以获取对应字段的值。

Java 8实战：流处理

Wed, 17 Feb 2021 18:00:13 +0800

流是一系列数据项，一次只生成一项。程序可以从输入流中一个一个读取数据项，然后以同样的方式将数据项写入输出流。一个程序的输出流很可能是另一个程序的输入流。基于流的思想，Java 8在 $java.util.stream$ 中添加了一个Stream API。 $Stream$<$T$> 就是一系列 $T$ 类型的项目。
和Collection API相比，Stream API处理数据的方式非常不同。用集合的话，需要使用 $for$ 循环迭代并处理元素，我们称之为外部迭代。相反，Stream API的数据处理完全是在库内部进行的，我们称之为内部迭代。虽然都能访问数据项目的序列，但是相比之下，Collection API主要是为了存储和访问数据，而Stream API主要用于描述对数据的计算。这里的关键点在于，Stream API允许并行处理一个 $Stream$ 中的元素。筛选一个 $Collection$ 最快的方式通常是将其转换为 $Stream$ ，进行并行处理，再转换回 $List$ 。粗略地说，流与集合之间的差异就在于什么时候进行计算。集合是一个内存中的数据结构，包含数据结构中目前所有的值，集合中的元素只有经过计算后才能添加；相比之下，流是在概念上固定的数据结构，不能通过流添加或删除元素，流中的元素是按需计算的，即只从流中提取出需要的值。与迭代器类似，流只能遍历一次。遍历完之后，我们就说这个流已经被消费掉了。要想重新遍历，可以从原始数据源中重新获取一个新的流。尝试再次遍历一个已经消费的流会抛出 $IllegalStateException$ 异常。流与集合的另一个关键区别在于遍历数据的方式，正如之前所说，使用 $Collection$ 接口需要用户进行外部迭代，而 $Steams$ 库使用的是内部迭代，即库自动完成迭代，并将流值存放在某个地方。相较于显式的外部迭代，内部迭代下项目可以透明地并行处理，或者用更优化的顺序进行处理，例如同时处理多个数据，或者优先处理某些数据等。

1. 流操作

操作	类型	返回类型	操作参数	函数描述符	目的
$filter$	中间	$Stream$<$T$>	$Predicate$<$T$>	$T \rightarrow boolean$	返回一个包含所有符合谓词的元素的流
$distinct$	中间	$Stream$<$T$>			返回一个元素各异的流
$map$	中间	$Stream$<$R$>	$Function$<$T, R$>	$T \rightarrow R$	将函数应用到每个元素上，并映射成一个新元素
$flatMap$	中间	$Stream$<$R$>	$Function$<$T,R$>	$T \rightarrow R$	将多个生成流扁平化为单个流
$limit$	中间	$Stream$<$T$>			返回一个不超过给定长度的流
$skip$	中间	$Stream$<$T$>			返回一个跳过给定数量元素的流
$sorted$	中间	$Stream$<$T$>	$Comparator$<$T$>	$(T, T) \rightarrow int$	返回一个经过排序的流
$forEach$	终端	$void$	$Consumer$<$T$>	$T \rightarrow void$	消费流中的每一个元素并对其应用`Lambda`，返回类型为 $void$
$count$	终端	$long$			返回流中元素的个数，返回类型为 $long$
$collect$	终端	$R$	$Collector$<$T, A, R$>		把流归约成一个集合并返回
$anyMatch$	终端	$boolean$	$Predicate$<$T$>	$T \rightarrow boolean$	流中是否含有一个元素能匹配给定的谓词
$allMatch$	终端	$boolean$	$Predicate$<$T$>	$T \rightarrow boolean$	流中的元素是否都能匹配给定的谓词
$noneMatch$	终端	$boolean$	$Predicate$<$T$>	$T \rightarrow boolean$	流中是否没有元素与给定的谓词匹配
$findAny$	终端	$Optional$<$T$>			返回当前流中的任意元素
$findFirst$	终端	$Optional$<$T$>			返回当前流中第一个元素
$reduce$	终端	$Optional$<$T$>	$BinaryOperator$<$T$>	$(T, T) \rightarrow T$	对流中元素重复应用方法

        诸如 $filter$ 或 $Sorted$ 等操作会返回另一个流，这让多个操作可以连接起来形成一个查询，这种操作称为中间操作。除非流水线上触发一个终端操作，否则中间操作不会执行任何处理。终端操作会从流的流水线生成结果，其结果是任何不是流的值，比如 $List$ 、$Integer$ 等。总而言之，流的使用一般包括三件事：一个数据源、一个中间操作链和一个终端操作。
        诸如 $map$ 或 $filter$ 等操作会从输入流中获取每一个元素，并在输出流中得到 $0$ 或 $1$ 个结果。这些操作一般都是无状态操作。但诸如 $reduce$ 、$sum$ 、$max$ 等操作需要内部状态来累计结果，这些操作就是有状态操作。但是这些操作的内部状态很小，通常只是一些基本数据类型，不管流中有多少元素需要处理，内部状态都是有界的。而诸如 $sorted$ 或 $distinct$ 等操作，它们的内部状态可能很大，这时就要求无界的存储空间。
        $peek$ 是一个特殊的流操作，可以在流的每个元素恢复运行之前，插入执行一个动作。$peek$ 不会恢复流的运行，而是在一个元素上完成操作之后，将操作顺承到流水线中的下一个操作。
        Java 8引入了三个原始类型特化流接口 $IntStream$ 、$DoubleStream$ 和 $LongStream$ ，分别将流中的元素特化为 $int$ 、$long$ 和 $double$ ，从而避免了暗含的装箱成本。每个接口都带来了进行常用数值归约的新方法，比如对数值流求和的 $sum$ ，此外还可以在必要时将它们转换回对象流。将流转换为特化版本的常用方法是 $mapToInt$ 、$mapToDouble$ 和 $mapToLong$ 。这些方法和 $map$ 的工作方式一样，但是会返回特化流。如果想要将特化流转换为对象流，可以使用 $boxed$ 方法。类似的，也可以使用 $mapToObj$ 方法生成对象流。
        Java 8还引入了两个可以用于 $IntStream$ 和 $LongStream$ 的静态方法，帮助生成数值范围，分别是 $range$ 和 $rangeClosed$ ，前者为开区间，后者为闭区间。
        除了调用集合中的 $stream$ 方法之外，还有一些其他的构造流的方式：

JVM（10）：线程安全与锁优化

Wed, 13 Jan 2021 21:17:10 +0800

1. 线程安全

按照线程安全程度由强到弱，可以将Java语言中各种操作共享的数据分为以下五类：不可变、绝对线程安全、相对线程安全、线程兼容和线程对立。

1.1 不可变

在Java语言里，不可变 ( $Immutable$ ) 对象一定是线程安全对象，因此不需要进行任何线程安全保障措施。对于基本数据类型，只需要在定义时使用 $final$ 关键字即可保证不可变。而对于对象类型，Java语言目前暂时还没有提供支持，因此只能让对象自行保证行为不会影响状态，其中最简单的一种方式就是把所有带有状态的变量都声明为 $final$ 。

1.2 绝对线程安全

绝对线程安全指的是当多个线程同时访问一个对象时，如果不用考虑这些线程在运行时环境下的调度和交替执行，也不需要额外的同步，或者在调用方进行任何其他的协调操作，调用这个对象的行为都可以获得正确的结果。而实际上，要想达到绝对线程安全可能需要付出非常高昂的代价。Java API中标注线程安全的类，大多数都不是绝对线程安全的。例如 $java.util.Vector$ 是一个线程安全的容器，因为它的很多方法被 $synchronized$ 修饰，但是在以下情况下还是线程不安全的：

private static Vector<Integer> vector = new Vector<>();

public static void main(String[] args) {
    while (true) {
        for (int i = 0; i < 10; i++) vector.add(i);

        Thread removeThread = new Thread(new Runnable() {
            @Override
            public void run() {
                for (int i = 0; i < vector.size(); i++) vector.remove(i);
            }
        });

        Thread printThread = new Thread(new Runnable() {
            @Override
            public void run() {
                for (int i = 0; i < vector.size(); i++)
                    System.out.println(vector.get(i));
            }
        });

        removeThread.start();
        printThread.start();
    }
}

而要想做到线程安全，需要将上述代码改为如下形式：

JVM（9）：内存模型与线程

Tue, 12 Jan 2021 21:13:32 +0800

1. 内存模型

1.1 主内存与工作内存

Java内存模型的主要目的是定义程序中各种变量的访问规则，即关注在虚拟机中把变量值存储到内存和从内存中取出变量值这样的底层细节。在这里主要考虑的问题是多线程对同一块内存区域进行的操作，因此并不需要考虑一些线程私有的变量比如局部变量和方法参数。Java内存模型规定了所有变量都存储在主内存 ( $Main\ \ Memory$ ) 中，每条线程允许拥有自己的工作内存 ( $Working\ \ Memory$ )，保存了主内存中要使用的变量的副本。对于引用对象，工作内存中并不会包含整个对象的副本，而是对象引用以及对象中要使用的字段的副本。通过工作内存，线程的所有的对变量的操作都会在工作内存中进行，即通过工作内存间接访问主内存。

1.1 内存间交互

主内存与工作内存之间的交互协议指的是一个变量如何从主内存拷贝到工作内存，并从工作内存同步至主内存的过程。Java内存模型定义了 $8$ 种原子性操作：

$lock$ ：作用于主内存变量，将变量标识为线程独占状态；
$unlock$ ：作用于主内存变量，把释放一个处于线程独占状态的变量；
$read$ ：作用于主内存变量，将一个变量传输到工作内存中；
$load$ ：作用于工作内存变量，将一个主内存传输的变量载入工作内存的副本中；
$use$ ：作用于工作内存变量，每当虚拟机遇到一个需要使用变量的字节码指令时，将变量传递给执行引擎；
$assign$ ：作用于工作内存变量，每当虚拟机遇到一个给变量赋值的字节码指令时，从执行引擎接收值并赋给变量；
$store$ ：作用于工作内存变量，将一个变量传送到主内存中；
$write$ ：作用于主内存变量，将一个工作内存传送的变量写入主内存的变量中。

如果要把一个变量从主内存拷贝到工作内存中，就需要顺序执行 $read$ 和 $load$ 操作；反过来，如果要把一个变量从工作内存拷贝到主内存中，就需要顺序执行 $store$ 和 $write$ 操作。Java内存模型虽然规定了上述操作要顺序执行，但并没有要求连续执行，也就是说可以读取多个变量后再依次载入，或者存储多个变量后再依次写入。除此之外，还有其他规则：

不允许 $read$ 和 $load$ 、$store$ 和 $write$ 单独出现；
不允许线程丢弃 $assign$ 操作；
不允许线程在没有进行 $assign$ 操作时同步内存；
不允许在工作内存中直接 $use$ 一个未被初始化的变量；
一个变量在一个时刻只能被一个线程 $lock$ ，一个线程可以多次执行 $lock$ 操作，后续需要执行相应次数的 $unlock$ 才能解锁；
对一个变量执行 $lock$ 操作会清除变量值，需要重新执行 $load$ 或者 $assign$ 进行赋值；
不允许对一个没有被锁定的变量 $unlock$ ，也不允许 $unlock$ 其他线程独占的变量；
$unlock$ 变量前需要先对其进行 $store$ 和 $write$ 。

1.2 `volatile`

        $volatile$ 具有一些特殊的访问规则。当一个变量被定义为 $volatile$ 之后，它将具有两条性质：一是保证变量是所有线程可见的，即一个线程的修改可以在之后被另一个线程所发现；二是指令重排序优化会被禁止，以保证语句之间的相对执行顺序。虽然可见性使得线程间变量值的传递不再需要经过对主内存的读取和写入，但这并不意味读取到的变量值是正确的。因为 $volatile$ 允许多线程同时对变量进行写操作，这就意味着对于一些非原子性的操作，譬如Java中的运算操作符（需要先将值读取到操作栈之后才能进行运算），$volatile$ 只能保证值被读取的时候是正确的，并不能保证在之后进行运算的过程中值不会发生改变。因此对于第一条性质，要保证运算结果并不依赖变量的当前值，或者只有一个线程会修改变量值。
        保证 $volatile$ 可见性的关键在于 $lock$ 操作，它会清空变量值，并在之后对变量进行 $store$ 和 $write$ 操作，从而保证了对变量的修改可以被其他线程发现。同时，$lock$ 操作也充当着内存屏障的功能，即执行 $lock$ 操作代表之前的操作已经执行完毕，从而可以利用 $lock$ 操作保证指令之间的相对执行顺序。也因此，$volatile$ 相比于 $synchronized$ 或者 $java.util.concurrent$ ，读操作速度没有什么差别，但是写操作会慢上一些，因为需要插入许多内存屏障以保证执行顺序，当然总体上来讲还是要快于后两者的。
        Java内存模型也对 $volatile$ 变量定义了特殊规则，设 $V$ 和 $W$ 代表两个 $volatile$ 变量，则有：

JVM（8）：后端编译与优化

Sat, 09 Jan 2021 20:58:35 +0800

1. 即时编译器

目前主流的两款商用Java虚拟机里，Java程序最初都是通过解释器执行的。当虚拟机发现某个方法或者代码块运行频繁，就会把代码认为是热点代码 ( $Hot\ \ Spot\ \ Code$ )，并将这些代码编译为本地机器码，同时进行代码优化。完成这个任务的后端编译器就称为即时编译器。

1.1 解释器与编译器

        当程序需要迅速启动和执行时，解释器可以省去编译时间立即运行；当程序启动后，越来越多的代码会被编译成本地代码，从而减少解释器带来的中间损耗，获得更快的执行速度。如果程序运行环境中内存限制过大，可以使用解释执行从而节约内存，反之可以使用编译执行提升效率。当编译器采取的优化手段出现罕见陷阱 ( $Uncommon\ \ Trap$ ) 时，可以通过逆优化 ( $Deoptimization$ ) 退回到解释状态执行。
        HotSpot虚拟机中内置了两个（或三个）即时编译器，其中两个存在已久的编译器分别称为客户端编译器 ( $Client\ \ Compiler$ ) 和服务端编译器 ( $Server\ \ Compiler$ )，简称为 $C1$ 编译器和 $C2$ 编译器。第三个编译器是JDK 10时出现的，目标是替代 $C2$ 的 $Graal$ 编译器。
        在分层编译 ( $Tiered\ \ Compilation$ ) 的工作模式出现前，通常采用解释器与一个编译器直接搭配的方式工作，这时用户也可以通过 $-client$ 和 $-server$ 参数直接运行模式。解释器与编译器搭配使用的方式称为混合模式 ( $Mixed\ \ Mode$ )，也可以通过 $-Xint$ 或者 $-Xcomp$ 强制运行解释模式或者编译模式。
        即时编译需要占用程序运行时间，而且编译过程中还需要进行优化。要想达到好的优化效果，解释器需要替编译器收集性能监控信息。当然，这也会影响解释执行的速度。为了寻求启动响应速度与运行效率之间的平衡，HotSpot虚拟机在编译子系统中加入了分层编译，包括：

第 $0$ 层，程序解释执行，不开启性能监控；
第 $1$ 层，使用客户端编译器，进行简单优化，不开启性能监控；
第 $2$ 层，使用客户端编译器，开启方法和回边次数统计等监控；
第 $3$ 层，使用客户端编译器，开启全部性能监控，除了第 $2$ 层的统计信息外，还会收集分支跳转、虚方法等统计信息；
第 $4$ 层，使用服务端编译器将字节码编译为本地代码，需要更多的优化，还可能采取一些不可靠的激进优化。

实施分层编译后，解释器、客户端编译器、服务端编译器就会同时工作，热点代码可能会被多次编译。使用客户端编译器编译可以获得更高的编译速度，使用服务端编译器可以获得更好的编译质量。

JVM（7）：前端编译与优化

Fri, 08 Jan 2021 20:09:14 +0800

1. `Javac`编译器

Javac是一个由Java语言编写的程序，从其代码总体结构来看，可以将编译过程大致分为 $1$ 个准备过程和 $3$ 个处理过程：

准备过程：初始化插入式注解处理器
解析与填充符号表过程，包括词法分析、语法分析和符号表创建
插入式注解处理器的注解处理过程
分析与字节码生成过程，包括标注检查、数据流及控制流分析、解语法糖和字节码生成

在上述处理过程中，执行插入式注解时可能又会产生新的符号。如果产生新的符号，就必须对它们进行解析，因此又回到了步骤 $2$ 。Javac编译动作的入口是 $com.sun.tools.javac.main.JavaCompiler$ 类，上述 $3$ 个过程的代码逻辑集中在这个类的 $compiler(\ )$ 和 $compiler2(\ )$ 方法。

1.1 解析与填充符号表

解析过程通过 $JavaCompiler.parseFiles(\ )$ 方法发起。

1.1.1 词法、语法分析

词法分析过程由 $com.sun.tools.javac.parser.Scanner$ 类完成。语法分析过程由 $com.sun.tools.javac.parser.Parser$ 类完成，产出的抽象语法树以 $com.sun.tools.javac.tree.JCTree$ 类表示。在完成词法、语法分析之后，编译器后续的操作都建立在抽象语法树的基础上，不会再对源码进行操作了。

1.1.2 填充符号表

填充符号表过程通过 $JavaCompiler.enterTrees(\ )$ 方法发起，由 $com.sun.tools.javac.comp.Enter$ 类完成，产出一个待处理列表，其中包含了每一个编译单元的抽象语法树的顶级结点。

1.2 注解处理器

在JDK 5时，注解只会在程序运行期间发挥作用。JDK 6中提供了一组称为“插入式注解处理器”的标准API，使得特定注解的处理可以提前至编译期进行。插入式注解处理器可以读取、修改和添加抽象语法树的元素。如果在这个过程中发生了修改操作，那么编译器需要返回解析与填充符号表过程重新处理。

1.3 语义分析与字节码生成

抽象语法树能够表示一个结构正确的源程序，但无法保证源程序的语义符合逻辑，因此需要进行语义分析对源程序进行上下文相关性质的检查，譬如类型检查、控制流检查、数据流检查等。

1.3.1 标注检查

标注检查由 $JavaCompiler.attribute(\ )$ 方法发起。标注检查步骤要检查的内容包括变量使用前是否已声明、变量与赋值之间的数据类型是否匹配等。此外还会进行常量折叠 ( $Constant\ \ Folding$ ) 。

1.3.2 数据及控制流分析

数据及控制流分析是对程序上下文逻辑的更进一步验证，可以检查出诸如程序局部变量在使用前是否有赋值、方法的每条路径是否都有返回值、是否所有受查异常都被正确处理等。编译期的数据及控制流分析与类加载时的数据及控制流分析的目的基本上可以看作是一致的，但有一些校验项只有在编译期或者运行期才能进行。数据及控制流分析由 $JavaCompiler.flow(\ )$ 方法发起，由 $com.sun.tools.javac.comp.Flow$ 类完成。

JVM（6）：字节码执行引擎

Wed, 14 Oct 2020 17:02:05 +0800

1. 运行时栈帧

JVM以方法作为最基本的执行单元，栈帧 ( $Stack\ \ Frame$ ) 是用于支持虚拟机进行方法调用和方法执行背后的数据结构，也是虚拟机运行时数据区中的虚拟机栈 ( $Virtual\ \ Machine\ \ Stack$ ) 的栈元素，存储了方法的局部变量表、操作数栈、动态连接和方法返回地址和一些额外的附加信息，方法表的 $Code$ 属性包含了栈帧所需的局部变量表和操作数栈的大小。对于执行引擎来讲，在每个线程中，只有处于调用堆栈栈顶的方法才是正在运行的方法，称为当前栈帧 ( $Current\ \ Stack\ \ Frame$ )，与这个栈帧关联的方法称为当前方法 ( $Current\ \ Method$ )。

1.1 局部变量表

        局部变量表 ( $Local\ \ Variable\ \ Table$ ) 是一组变量值的存储空间，用于存放方法参数和方法内部定义的局部变量，其最大容量由方法 $Code$ 属性中的 $max_-locals$ 数据项决定。局部变量表以变量槽 ( $Variable\ \ Slot$ ) 为最小单位，每个变量槽都应该能存放一个 $boolean$ 、$byte$ 、$char$ 、$short$ 、$int$ 、$float$ 、$reference$ 或 $returnAddress$ 类型的数据。这些数据长度一般都为 $32$ 位 ( $reference$ 可能为 $64$ 位 )，也意味着变量槽的长度至少为 $32$ 位。而对于 $64$ 位的数据类型，比如 $long$ 和 $double$ ，会通过高位对齐的方式分配两个连续的变量槽。
        JVM通过索引定位的方式使用局部变量表。对于 $32$ 位数据类型的变量，使用一个索引值；对于 $64$ 位数据类型的变量，使用相邻的两个索引值。当方法被调用时，JVM使用局部变量表将参数值传递到参数变量列表，即从实参到形参。如果方法为实例方法，那么局部变量表第 $0$ 位索引的变量槽默认为传递方法所属对象实例的引用。在参数表分配完毕后，再根据方法体内部定义的变量顺序和作用域分配其余的变量槽。因为方法中定义的变量的作用域不一定会覆盖整个方法体，因此变量槽是可以重用的。
        局部变量槽会影响系统的垃圾收集行为，可以观察以下三种情况：

JVM（5）：类加载

Tue, 22 Sep 2020 22:20:52 +0800

1. 类加载的时机

一个类型从被加载到卸载的过程中，会经历加载 ( $Loading$ )、验证 ( $Verification$ )、准备 ( $Preparation$ )、解析 ( $Resolution$ )、初始化 ( $Initialization$ )、使用 ( $Using$ ) 和卸载 ( $Unloading$ ) 七个阶段，其中可以把验证、准备、解析统称为连接 ( $Linking$ )。这些阶段之间可以交叉进行。加载、验证、准备、初始化、卸载的顺序是确定的，解析阶段则不一定，可能开始在初始化之后。
《Java虚拟机规范》中并没有规定什么时候需要进行加载，但是严格规定了有且只有六种情况需要进行初始化：

执行 $new$ 、$getstatic$ 、$putstatic$ 、$invokestatic$ 四条字节码指令时，如果类型没有初始化，需要先进行初始化阶段。这四条字节码指令分别对应：使用 $new$ 创建对象实例、读取和设置静态字段 ( $final$ 字段除外，因为它在编译器就已被置入常量池 )、调用静态方法；
对类型进行反射调用时，如果类型没有初始化，需要先进行初始化阶段；
初始化类时如果父类没有初始化，需要先初始化父类；
虚拟机启动时，主类需要先进行初始化；
JDK 7之后，如果一个 $java.lang.invoke.MethodHandle$ 实例的解析结果为 $REF_-getStatic$ 、$REF_-putStatic$ 、$REF_-newInvokeSpecial$ 四种类型的方法句柄时，如果该方法句柄对应的类没有初始化，需要先进行初始化阶段；
JDK 8之后，接口中包含 $default$ 方法时，在其实现类发生初始化前，需要先进行接口的初始化阶段。

这六种情况触发初始化场景的行为称为主动引用，除此之外的引用称为被动引用。例如通过子类访问父类的静态字段并不会触发子类的初始化，只会触发父类的初始化；声明一个引用数组并不会触发引用类型的初始化，而是初始化一个数组类型。
与类相同，接口也具有初始化过程。虽然接口中不能使用静态代码块，但是编译器仍然会生成 <$clinit$>$(\ )$ 类构造器，用于初始化成员变量。在前面的六种主动引用触发场景中，只有在初始化父类时才会对接口进行初始化。但是一个接口在初始化时，并不要求其父接口全部初始化，只有在用到时才需要进行初始化。

2. 类加载的过程

2.1 加载

类加载过程，虚拟机需要完成以下三件事：

通过类的全限定名获取二进制字节流；
将字节流所代表的静态存储结构转为方法区的运行时数据结构；
在内存中生成一个代表这个类的 $java.lang.Class$ 对象，作为方法区中该类各种数据的访问入口。

由于没有限制获取字节流的位置，因此可以从许多地方以许多方式获取，例如从Jar包、War包获取，从JSP文件获取、从数据库中读取等。相较于其他阶段，非数组类型的类加载的可控性很强，可以通过自定义的类加载器完成。数组类的加载十分特殊，它并不依赖类加载器，而是由JVM在内存中直接构造。但是数组类仍然与类加载器有着密切关系，因为其元素类型仍然需要依赖类加载完成加载。一个数组类的创建规则如下：

回溯算法：八皇后

Sat, 19 Sep 2020 16:11:12 +0800

原题地址：Problem 51

将 $N$ 个皇后放在 $N \times N$ 的棋盘上，要求皇后不能处于同行、同列、同对角线上。没有什么取巧的方案，只能尝试所有情况后将可行的情况列出，因此可以使用回溯算法。
此题的难点在于判断皇后之间是否能相互攻击。如果将皇后所处的格子视为 $1$ ，其它格子视为 $0$ ，那么就可以使用位运算来判断。保证皇后不同行的方式很简单，只需要保证每一行只放置一个皇后即可。而如果想要保证皇后不同列，就需要记录之前行的皇后的位置。我们可以通过按位或和按位和进行记录和判断。

$$ .\ \ Q\ .\ \ .\ \ \\ .\ \ .\ \ .\ \ Q\ \\ Q\ .\ \ .\ \ .\ \ \\ .\ \ .\ \ Q\ .\ \ \\ $$

对于上面的例子，第一行我们可以记为 $0100$ 。到第二行通过按位和进行判断：$0100 \And 0001$ ，如果不为 $0$ ，说明发生冲突。如果没有冲突，那么可以通过按位或获取新值：$0100 | 0001 = 0101$ 。重复上述步骤即可保证皇后处于不同列。
如果要保证皇后不处于同对角线，进行观察可以发现：下一行的皇后不能处于上一行皇后的左一格或者右一格，不能处于上上一行皇后的左二格或者右二格……也就是每过一行，就让之前行的皇后统一左移或者右移一格，然后再使用类似于之前判断皇后是否同列的方法进行判断就行了。我们可以使用两个数字 $left$ 和 $right$，专门用于记录之前行皇后的左移或者右移。再以上面的例子，第二行的 $left$ 为 $1000$ ，第三行为 $0010$ ；第二行的 $right$ 为 $0010$ ，第三行的 $right$ 为 $0001$ 。

JVM（4）：Class文件结构

Thu, 17 Sep 2020 22:58:37 +0800

1. 平台无关性

Java在刚刚诞生时就有一句非常著名的口号：一次编写，到处运行。这个想法通过虚拟机实现，这些虚拟机都可以执行同一种与平台无关的字节码，从而达到一次编写，到处运行。可以说，字节码就是平台无关性的基石。Java虚拟机并不与Java语言绑定，在其之上还可以运行许多其他语言，如Kotlin、Groovy和Scala等。Java虚拟机唯一绑定的是类似于Class文件这种特殊的二进制文件，其中包含了Java虚拟机的指令集、符号表以及其他辅助信息。通过Class文件，Java虚拟机并不需要关心来源是什么语言，只要这门语言能够生成可以被读取的Class文件，那么它就可以在Java虚拟机上运行。
Java语言中的各种语法、关键字、常量变量和运算符号的语义最终都会转成字节码指令的组合，这就要求字节码指令的表达能力必须比Java语言的表达能力更强。从而，一些Java语言中并不支持的特性，字节码也能够表达出来。

2. `Class`类文件

Class文件是一组以 $8$ 个字节为单位的二进制流，数据项目按照顺序紧凑地排列在文件之中。对于 $8$ 字节以上空间的数据项，会按照高位在前的大端序分割存储在若干个 $8$ 字节中。
Class文件采取一种类似于C语言结构体的伪结构来存储数据，包含两种数据类型：

无符号数：即基本数据类型，通过 $u1$ 、$u2$ 、$u3$ 、$u4$ 分别表示 $1$ 个字节、$2$ 个字节、$4$ 个字节和 $8$ 个字节的无符号数，用于表示数字、索引引用、数量值或者UTF-8编码的字符串；
表：由多个无符号数或者其他表构成的复合数据类型，一般以 $_-info$ 结尾，用于表示具有层次关系的数据。可以把整个Class文件都视为表，按照对应类型的数据紧凑排列而成。

当需要描述类型相同但数量不定的数据时，经常会使用一个前置的容器计数器加若干个连续的数据项的形式，称为该类型的集合。

2.1 魔数和版本号

Class文件的头 $4$ 字节称为魔数 ( $Magic\ \ Number$ )，用于确定该文件能否被虚拟机接受。魔数在很多文件格式中都存在，文件格式制定者可以自定义魔数，只要不会引起混淆。Class文件的魔数为 $0xCAFEBABE$ ，象征着一款咖啡。
在魔数之后是Class文件的版本号，前两个字节是次版本号 ( $Minor\ \ Version$ )，后两个字节是主版本号 ( $Major\ \ Version$ )。Java主版本号从 $45$ 开始，JDK 1.1之后每个大版本都会在之前的基础上加 $1$ 。次版本号在JDK 1.1及以前曾经短暂使用过，在JDK 1.2之后废弃，全部使用 $0$ 代替，直到JDK 12，由于一些复杂特性需要进行公测，于是重新启用了次版本号。

2.2 常量池

常量池是Class文件中第一次出现表的数据项目，也是与其他项目关联最多的数据，通常也是最庞大的数据项目之一。常量池入口是一个 $u2$ 类型的数据，是常量池容量计数值 ( $constant_-pool_-count$ )，从 $1$ 开始，$0$ 表示不指向常量池中的数据项目。Class文件中只有常量池的容量计数是从 $1$ 开始的。
常量池中主要存放字面量 ( $Literal$ ) 和符号引用 ( $Symbolic\ \ References$ )。字面量类似于Java中的常量，存放字符串、$final$ 常量等。符号引用则属于编译原理方面的概念，包括：

快速乘算法简介

Tue, 15 Sep 2020 15:05:04 +0800

快速乘算法的原理是俄罗斯农民乘法，这种乘法规则很简单：

将要相乘的两个数字写在两列；
将第一列乘以二，第二列除以二并写在下一行；
如果这一行中第二列数字为偶数，删去这一行；
在下一行重复上述二至三步直至第二列数字为 $1$ ；
将第一列未被删除的数字求和即为结果

以 $48 \times 58$ 为例：

$$ \require{cancel} \bcancel{48}\qquad\bcancel{58}\\ 96\qquad29\\ \bcancel{192}\qquad\bcancel{14}\\ 384\qquad7\\ 768\qquad3\\ 1536\qquad1\\ ————\\ 2784\qquad $$

从而 $48 \times 58 = 2784$ 。
运用这个原理，我们可以对二进制数进行计算，只需要将原来的规则调整下即可。对于二进制数 $A$ 和 $B$ ，如果要计算 $A \times B$ ，那么可以：

如果 $B$ 末位为 $1$ ，将 $A$ 加到结果上；
将 $A$ 左移一位，$B$ 右移一位；
重复上述两步直至 $B$ 为零。

将上述步骤用代码实现如下：

class QuickMulti {
    public int quickMulti(int A, int B) {
        int res = 0;
        while (B != 0) {
            if (B & 1 == 1) res += A;
            A <<= 1;
            B >>= 1;
        }
        return res;
    }
}

在这里举一道题为例演示快速乘算法的使用：求1+2+…+n 。
题目描述很简单，但要注意不能使用循环，即迭代，因此可以使用递归代替。不能使用条件判断语句，因此需要借助 $\And\And$ 逻辑运算符近似实现 $if$ 。而在Java中并不能直接在一条语句中使用 $\And\And$ ，因此可以先声明一个 $boolean$ 变量。实现代码如下：

Java注解

Mon, 07 Sep 2020 23:32:11 +0800

注解为在代码中添加信息提供了一种形式化的方式。Java SE5内置了三种定义在 $java.lang$ 当中的注解：

$@Override$ ：表示当前定义的方法将覆盖超类中的方法；
$@Deprecated$ ：表示方法被弃用，调用此类方法将引发警告；
$@SuppressWarnings$ ：关闭某些编译警告信息。

除此之外还有四种注解，用于创建新注解。

1. 语法

1.1 定义

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface Test {
    public int id();
    public String description() default "no description";
}

注解的定义方式很像接口，也与接口一样会被编译为class文件。定义注解需要一些元注解。$@Target$ 定义注解的作用对象，如方法；$@Retention$ 定义的可用级别，分为源码 ( $SOURCE$ )、类文件 ( $CLASS$ )、运行时 ( $RUNTIME$ )。
在定义注解时也可以设置一些元素表示一些值，不同于接口，你可以为这些值设置默认值。如果没有提供默认值，那么在使用注解的时候就必须进行赋值。没有元素的注解称为标记注解 ( $marker\ \ annotation$ )。可用的注解元素包括以下类型：

基本类型；
$String$ ；
$Class$ ；
$enum$ ；
$Annotation$ ；
以上类型的数组。

1.2 元注解

Java内置了四种元注解：

$@Targe$ ：表示注解的作用对象，包括：
- $CONSTRUCTOR$ ：构造器；
- $FIELD$ ：域，包括 $enum$ 实例；
- $LOCAL_-VARIABLE$ ：局部变量；
- $METHOD$ ：方法；
- $PACKAGE$ ：包；
- $PARAMETER$ ：参数；
- $TYPE$ ：类、接口（包括注解）和 $enum$ 声明；
$@Retention$ ：表示在什么级别保存注解信息，包括：
- $SOURCE$ ：源码，注解将被编译器丢弃；
- $CLASS$ ：class文件，注解将被JVM丢弃；
- $RUNTIME$ ：运行时，因此可以通过反射获取注解信息；
$@Documented$ ：将此注解包含在Javadoc中；
$@Inherited$ ：允许子类继承父类中的注解。

2. 注解处理

注解需要搭配注解处理器使用，可以通过反射机制创建自己的注解处理器。

Java I/O

Sun, 06 Sep 2020 21:28:06 +0800

1. `File`类

$File$ 类用于储存文件路径，可以代表一个特定文件或者一组文件的名称，如果是后者，可以通过 $list(\ )$ 获得一个字符数组。在不传入参数时，$list(\ )$ 方法返回全部列表，也可以接受一个 $FilenameFilter$ 类型的参数，实现目录过滤：

class DirFilter implements FilenameFilter {
    private Pattern pattern;
    public DirFilter(String regex) {
        pattern = Pattern.compile(regex);
    }

    public boolean accept(File dir, String name) {
        return pattern.matcher(name).matches();
    }
}

public class DirList {
    public static void main(String[] args) {
        System.out.println(Arrays.toString(new File(".").list(new DirFilter(args[0]))));
    }
}

除了代表文件和目录之外，$File$ 对象还可以用于创建和删除目录，查看文件信息等：

方法	作用
$getAbsolutePath$	返回绝对路径
$canRead$	可读性
$canWrite$	可写性
$getName$	返回名称
$getParent$	返回父目录
$getPath$	返回路径
$lastModified$	最后修改时间
$isFile$	是否为文件
$isDirectory$	是否为目录
$exists$	是否存在
$mkdirs$	创建
$delete$	删除
$renameTo$	重命名或移动文件

2. `I/O`类

编程语言的I/O类库常使用流这个概念，代表任何有能力产出数据的数据源或者有接受能力的接收端对象。“流”屏蔽了设备处理I/O操作的细节。在Java中，任何由 $InputStream$ 和 $Reader$ 的类都含有 $read(\ )$ 方法，任何由 $OutputStream$ 和 $Writer$ 派生的类都含有 $write(\ )$ 方法。$InputStream$ 和 $OutputStream$ 类型用于处理单个字节，$Reader$ 和 $Writer$ 类型用于处理字节数组。一般情况下都是通过叠加多个对象提供功能，也因此，当需要一个流的时候，往往需要创建多个对象。

Java泛型

Wed, 02 Sep 2020 21:23:39 +0800

泛型允许一个类应用于多种类型，实现了参数化类型的概念。促使泛型产生的原因之一就是容器类，泛型可以用于指定一个容器具体要持有怎样的类型。当然，也可以通过泛型实现持有多个类型的类，如元组类：

public class TwoTuple<A, B> {
    public final A first;
    public final B second;

    public TwoTuple(A a, B b) {
        this.first = a;
        this.second = b;
    }
}

        如果需要长度更长的元组如三元组，我们可以在二元组的基础上声明三元组类，并令其继承二元组类。
        除了具体类外，泛型还可以应用于抽象类和接口当中。
        Java泛型存在着很多局限性，第一个就是不能以基本类型作为其类型参数。当然，通过Java自动包装和自动拆包的功能，基本类型和其包装类型可以很方便地进行转换。
        之前提到的泛型都是应用于一个类上的，但是泛型同样可以应用于方法上，而且不仅可以应用于泛型类的方法上，也可以应用于普通类的方法上。如果通过使用泛型方法就可以避免使用泛型类，那么推荐使用泛型方法。此外，由于 $static$ 方法无法获取类型参数，因此如果要让 $static$ 方法使用泛型，那么就必须让其成为泛型方法。与使用泛型类不同，使用泛型方法时可以不用指定具体类型，通过类型参数推断，编译器可以为我们找出具体类型。

1. 擦除

通过泛型，我们可以声明一个 $ArrayList<Integer>$ 对象，然后我们可以获取 $ArraysList.class$ ，但是却不能获取 $ArrayList<Integer>.class$ 对象。这个行为说明了在编译器的眼中，$ArrayList<Integer>$ 和 $ArrayList<String>$ 是同一类型。更加夸张的是，不同于C++，在Java的泛型内，你无法获取任何有关于泛型参数类型的信息。这些行为的原因都是因为Java的泛型是使用擦除实现的。在基于擦除的实现中，泛型被认为是第二类类型，既不能在某些重要的上下文环境中使用的类型。泛型类型只有在静态类型检查期间才会出现，之后泛型类型将被擦除，并替换为非泛型边界如 $List$ , $Object$ 等。
在C++中，我们可以实现以下代码：

template<class T> class Test {
    T obj;
public:
    Test(T t) {
        this.obj = t;
    }
    void f() {
        obj.f();
    }
}

但是在Java中，这种行为就无法实现了。因为擦除的存在，Java编译器无法认为 $obj$ 含有 $f(\ )$ 方法。而为了调用 $f(\ )$ ，在Java中需要这样实现：

Java类型信息

Sun, 30 Aug 2020 16:50:55 +0800

运行时类型信息 ( $RTTI$ ) 可以让我们在程序运行时发现和使用类型信息，主要有两种方式：传统RTTI，假定在编译时就已经知道了所有类型；以及反射，允许在运行时发现和使用类型信息。

1. `RTTI`

传统的RTTI在Java语句执行过程中也发挥着作用。

我们定义了一个 $Circle$ 对象，将其存储在一 $List<Shape>$ 容器之中。那么当对象被放入容器时，会向上转型为 $Shape$ ；而在取出时，由于 $List$ 容器会将所有对象当作 $Object$ 类型持有，因此会再次转换为 $Shape$ 对象。

1.1 `Class`对象

$Class$ 对象负责表示运行时的类型信息，Java通过 $Class$ 对象执行RTTI。每个类都拥有一个 $Class$ 对象，当它被编译时，就会通过类加载器产生一个 $.class$ 文件，存储其 $Class$ 对象。
所有的类都是在被第一次使用时动态地被加载到JVM当中的。当程序创建第一个对类的静态成员的引用时，就会加载这个类。也就是说构造器也是静态的，因此使用 $new$ 创建对象就会创建一个对静态构造器的引用，从而使得这个类被加载。当类的 $Class$ 对象被载入后，这个类的所有对象都会使用 $Class$ 对象创建。$Class$ 对象还有一些常用方法：

$forName(\ )$ ：通过全类名获取对应类的 $Class$ 对象；
$getName(\ )$ ：获取全限定的类名；
$getSimpleName(\ )$ ：获取不含包名的类名；
$getInterfaces(\ )$ ：$Class$ 对象中实现的接口；
$getSuperclass(\ )$ ：获取基类的 $Class$ 对象。

        $Class.newInstance(\ )$ 方法允许你在不知道确切类型的情况下创建对象。通过该方法你可以得到一个 $Object$ 对象，要想正确地使用该对象，你需要对其进行转型。使用 $newInstance$ 创建对象的要求是该对象拥有一个默认构造器。
        除了通过 $forName$ 获取 $Class$ 对象之外，还可以直接通过类字面常量获取，即访问一个类型的 $class$ 字段。而且因为这种方式在编译阶段就会受到检查，因此不需要对异常进行处理，所以也更高效。对于基本数据类型的包装类如 $Integer$ 这种，还拥有一个标准字段 $TYPE$ 。访问 $TYPE$ 就相当于访问对应基本类型的 $class$ 字段，即 $Integer.TYPE$ 相当于 $int.class$ 。
        普通的 $Class$ 对象可以被重新赋值为任何其他的类型的 $Class$ 对象。而要想避免这种再次赋值，可以通过泛型进行限定。
        在类型转换的过程中，Java要执行类型检查。如果执行了一个错误的类型转换，就会抛出一个 $ClassCastException$ 异常。RTTI还可以通过 $instanceof$ 进行检查，它用于判断某个对象是否是某个类型的实例，返回一个布尔值。

JVM（3）：性能监控和故障处理

Tue, 25 Aug 2020 20:11:27 +0800

1. 基础故障处理工具

基础故障处理工具是JDK自带的一些位于 $/bin$ 目录下的小工具。这些工具主要用于监视虚拟机运行状态和进行故障处理，根据软件可用性和授权的不同，可以分为三类：

商业授权工具：主要是JMC ( $Java\ \ Mission\ \ Control$ ) 及其使用的JFR ( $Java\ \ Flight\ \ Recorder$ )。自JDK 7开始集成，在JDK 11前都无需独立下载，但是商业使用需要收费。
正式支持工具：长期支持的工具，可能在不同平台和版本之间存在差异。
实验性工具：没有技术支持，具有实验性质的工具，但通常很稳定且具有强大功能。

1.1 `jps`：虚拟机进程状况工具

jps ( $JVM\ \ Process\ \ Status\ \ Tool$ ) 的名字类似于UNIX系统中的 $ps$ 命令，功能也和其类似：列出正在运行的虚拟机进程，并显示主类名称和本地虚拟机唯一ID ( $Local\ \ Virtual\ \ Machine\ \ Identifier$, $LVMID$ )。作为使用频率最高的JDK命令行工具，是其他工具查询进程的方法。对于本地虚拟机进程来说，LVMID与操作系统进程ID ( $Process\ \ Identifier$, $PID$ ) 是一致的，使用Windows任务管理器也可以查询到。但是如果存在多个虚拟机进程，使得无法通过进程定位时，jps命令显示的主类信息就可以帮助我们定位。

jps [options] [hostid]

$options$	作用
$-q$	输出`LVMID`，省略主类信息
$-m$	输出主类 $main$ 函数参数
$-l$	输出主类全名，如果为`JAR`包则输出路径
$-v$	输出`JVM`参数

$hostid$ 为RMI注册表中注册的主机名，jps可以通过RMI协议查询开启RMI服务的远程虚拟机进程状态。

JVM（2）：垃圾收集器

Sun, 23 Aug 2020 16:33:41 +0800

相比于程序计数器、虚拟机栈和本地方法栈这种应分配的内存大小在类确定时就已固定下来的内存区域，Java堆和方法区这两个区域有着不确定性：一个接口可能有多个实现类，一个方法可能有多个分支。垃圾收集器所关注的也就是这部分不确定的内存。

1. 对象状态

在进行垃圾收集之前，垃圾收集器需要对对象的状态进行判断，即判断其是否仍在被使用。

1.1 引用计数算法

引用计数 ( $Reference\ \ Counting$ ) 算法，可以简单的解释为在对象中添加一个引用计数器，当对象被引用时计数器便加一，反之减一。如此往复，当对象的引用计数器为零时，可以认为其不再被使用。虽然这种算法简单而且效率很高，但是因为存在着很多例外情况，因此不被主流的JVM所采纳。比较简单的例子就比如存在对象 $A$ 和 $B$ ，它们都存在着一个字段互相引用对方，这样它们的引用计数器就都为 $1$ 。但实际上，除了互相引用之外，它们没有被其他对象引用，可以认为是无用的对象，应该被垃圾收集。另一方面，它们的引用计数又不为 $0$ ，无法触发垃圾收集。因此，引用计数算法需要配合大量额外处理才能保证正常工作。

1.2 可达性分析算法

可达性分析 ( $Reachability\ \ Analysis$ ) 算法，基本思路就是通过一系列的称为GC Roots的根对象出发，不断搜索引用关系，搜索路径称为引用链 ( $Reference\ \ Chain$ )。当一个对象没有被搜索到，或者称不可达时，就认为这个对象不再被使用。在Java技术体系里固定可作为GC Roots的对象包括：

虚拟机栈中的引用对象
方法区中类静态属性的引用对象
方法区中常量引用对象
本地方法栈中JNI ( 即 $Native$ 方法 ) 的引用对象
JVM内部引用，如基本数据类型对应的 $Class$ 对象，一些常驻的异常对象等，还有系统类加载器
同步锁 ( $synchronized$ 关键字 ) 持有的对象
反应JVM内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等

除此之外，根据用户选择的垃圾收集器以及当前收集的内存区域，还会有临时对象的加入。譬如要针对某个特定区域进行垃圾收集时，不仅要加入该区域的，还要加入关联区域的其他对象。虽然现在查找引用链的过程已经可以做到并发，但迄今为止，所有收集器在根节点枚举这一步骤都要暂停用户线程。

1.3 对象引用

在JDK 1.2之前，Java对应用的定义为：如果 $reference$ 类型的数据中存储的数值代表的是另一块内存的起始地址，就称其代表某块内存或某块对象的引用。而在JDK 1.2之后，Java扩充了引用的概念，分为 $4$ 种引用强度：

强引用 ( $Strong\ \ Reference$ )：强引用是最传统的引用方式，即指引用赋值。
软引用 ( $Soft\ \ Reference$ )：软引用指一些有用但非必须的对象。当系统将发生内存溢出时，软引用对象会被回收。JDK 1.2之后提供了 $SoftReference$ 类实现软引用。
弱引用 ( $Weak\ \ Reference$ )：弱引用指非必须对象，但强度比软引用更弱。无论内存是否足够，都会被回收。JDK 1.2之后提供了 $WeakReference$ 类实现弱引用。
虚引用 ( $Phantom\ \ Reference$ )：虚引用是最弱的引用关系，不会对对象生命周期造成影响，也不能通过虚引用取得对象实例。关联虚引用只是为了在对象被回收之前获得系统通知。JDK 1.2之后提供了 $PhantomReference$ 类实现虚引用。虚引用需要与 $ReferenceQueue$ 联合使用，当垃圾收集器发现对象存在虚引用时，就会在回收前将虚引用加到与之关联的引用队列中。

1.4 对象死亡

一个对象的死亡至少需要经历两次标记过程：第一次为可达性分析，第二次为筛选，筛选覆盖了 $finalize(\ )$ 方法或者执行过 $finalize(\ )$ 方法的对象。如果 $finalize(\ )$ 方法未被覆盖或者未被执行，那么对象会进入 $F-Queue$ 队列，并在之后由一条自动建立的低优先级的 $Finalizer$ 线程执行其 $finalize(\ )$ 方法。稍后收集器会检查队列中的对象，如果对象在 $finalize(\ )$ 方法中建立了与其他对象的关联，那么它就会被移出队列。需要注意的是，为了避免长时间等待或者进入死循环，收集器并不会等待对象的 $finalize(\ )$ 方法执行完毕，而且一个对象的 $finalize(\ )$ 方法只能调用一次，因此有可能在下次对象回收时该对象不能再次自救。

JVM（1）：技术体系与内存区域

Wed, 19 Aug 2020 19:42:28 +0800

1. `Java`技术体系

从广义上来讲，Kotlin、Clojure、JRuby、Groovy等运行于Java虚拟机上的编程语言及其相关的程序都属于Java技术体系中的一员。从传统意义上来看，JCP官方所定义的Java技术体系包括以下几个部分：

Java程序设计语言
各种硬件平台上的Java虚拟机实现
Class文件格式
Java类库API
来自商业机构和开源社区的第三方Java类库

我们可以把Java程序设计语言、Java虚拟机、Java类库这三部分统称为JDK ( $Java\ \ Development\ \ Kit$ ) ，JDK是用于支持Java程序开发的最小环境。可以把Java类库API中的Java SE API子集和Java虚拟机这两部分统称为JRE ( $Java\ \ Runtime\ \ Environment$ )，JRE是支持Java程序运行的标准环境。
以上是按照Java组成部分来进行划分，如果按照技术领域来划分，则可以分为以下四条：

Java Card
Java ME
Java SE
Java EE

2. 自动内存管理

JVM在执行Java程序的过程中会将内存划分为若干个不同的数据区域。

2.1 程序计数器

程序计数器 ( $Program\ \ Counter\ \ Register$ ) 是一块比较小的内存空间，可以看作当前线程所执行的字节码的行号指示器。程序的分支、循环、跳转、异常处理、线程恢复等基础功能都要依赖这个计数器。在JVM中，一个处理器只会处理一个线程，多线程通过轮流切换来实现，因此每个线程都会有一个程序计数器。对于每个线程之间独立存储的内存，我们称之为“线程私有”内存。
Java中存在 $native$ 关键字，用于指示本地方法。通过 $native$ 关键字，Java程序可以调用本地应用（或库），也可以被其他程序调用。对于本地方法，在执行过程中，程序计数器的值为空 ( $Undefined$ )。而对于Java方法 ( 也就是字节码 ) ，程序计数器的值为正在执行的虚拟机字节码的指令地址。

2.2 `Java`虚拟机栈

        Java虚拟机栈 ( $Java\ \ Virtual\ \ Machine\ \ Stack$ ) 描述的是Java方法执行的线程内存模型。与程序计数器一样，它也是线程私有的。在每个方法被执行时，JVM都会同步创建一个栈帧 ( $Stack\ \ Frame$ ) 用于存储局部变量表、操作数栈、动态连接、方法出口等信息。在方法被调用时，这个栈帧会被压入Java虚拟机栈。当方法执行完毕时，其对应的栈帧也会被从Java虚拟机栈中弹出。如果将Java的内存区域像C/C++那样简单地划分为堆内存 ( $Heap$ ) 和栈内存 ( $Stack$ )，那么这里的虚拟机栈就可以视为栈内存。
        局部变量表中存储基本数据类型、对象引用以及 $returnAddress$ 类型 ( 指向一条字节码指令的地址 )。这些数据类型在局部变量表中以局部变量槽 ( $Slot$ ) 表示。对于 $64$ 位长度的 $long$ 和 $double$ 类型，它们将会占用两个槽。其余数据类型只占用一个。局部变量表的大小是在进入方法时就已确定的，不会随着运行而改变。
        当线程请求的栈深度大于虚拟机允许的深度时就会抛出 $StackOverflowError$ 异常。Java虚拟机栈的容量允许动态扩展。如果在扩展时无法申请到足够内存，那么就会抛出 $OutOfMemoryError$ 异常。

从零开始的JDK编译

Wed, 19 Aug 2020 05:40:45 +0800

首先从获取JDK源码开始。以OpenJDK为例，点击 OpenJDK 进入，选择对应的JDK版本，在此以JDK12为例，选择 $jdk12$ 。进入后在左侧选择 $browse$ ，然后再选择 $zip$ 即可下载。源码下载完毕之后解压，可以在解压后的文件目录下的 $/doc/building.html$ 中阅读编译文档。
源码下载完毕之后开始准备Linux环境，要注意在Linux环境中，文件夹请尽量使用英文名，名称中不要出现空格。我使用的是WSL Ubuntu，在刚开始使用时要记得切换镜像源。

vi /etc/apt/sources.list

使用 $vi$ 打开配置文件，然后替换为镜像源，在此我使用的是阿里云的镜像源，$sources.list$ 文件内容如下：

deb http://mirrors.aliyun.com/ubuntu/ bionic main restricted universe multiverse
deb http://mirrors.aliyun.com/ubuntu/ bionic-security main restricted universe multiverse
deb http://mirrors.aliyun.com/ubuntu/ bionic-updates main restricted universe multiverse
deb http://mirrors.aliyun.com/ubuntu/ bionic-proposed main restricted universe multiverse
deb http://mirrors.aliyun.com/ubuntu/ bionic-backports main restricted universe multiverse
deb-src http://mirrors.aliyun.com/ubuntu/ bionic main restricted universe multiverse
deb-src http://mirrors.aliyun.com/ubuntu/ bionic-security main restricted universe multiverse
deb-src http://mirrors.aliyun.com/ubuntu/ bionic-updates main restricted universe multiverse
deb-src http://mirrors.aliyun.com/ubuntu/ bionic-proposed main restricted universe multiverse
deb-src http://mirrors.aliyun.com/ubuntu/ bionic-backports main restricted universe multiverse

替换完毕后执行更新命令：

Geohash算法简介

Wed, 05 Aug 2020 19:58:48 +0800

1. `Geohash`算法介绍

Geohash-Wikipedia

Geohash是一种用于公共领域的地理编码系统，其将地理位置编码为字母和数字的短字符串。Geohash允许任意精度的属性，可以通过增长或缩短字符串来改变精度。当两个区域的公共前缀越长，说明他们的联系更加紧密。但是反过来，具有短公共前缀或者没有公共前缀并不一定代表着联系很小。
Geohash算法可以将一个二维的经纬度坐标转换成一个可以比较的字符串，也就是降维。使用三十二进制，全球被划分为 $32$ 个大块，再在每个大块内继续划分出 $32$个小块，因此对于越长的geohash字符串，其精度越大，代表的范围也就越小。通过Base32算法，geohash使用字母和数字表示值，如下所示：

数字	0	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进制	0	1	2	3	4	5	6	7	8	9	b	c	d	e	f	g	h	j	k	m	n	p	q	r	s	t	u	v	w	x	y	z

即使用了所有 $10$ 以内的数字，以及除 $a$, $i$, $l$ 和 $o$ 之外的所有小写字母。在计算的时候只需要在十进制和三十二进制之间转换即可，举例：

关于

Wed, 05 Aug 2020 11:00:59 +0800

个人博客，记录自己的学习历程。

有事请发邮件，虽然不能保证及时回复但是总能看到的。~~除非被当做垃圾邮件了~~

友链

Wed, 05 Aug 2020 11:00:59 +0800

莓道理的博客

Ayamir's Blog

Git常用指令汇总

Tue, 04 Aug 2020 19:36:05 +0000

创建仓库/init

git init

创建成功后当前目录下会生成一个.git目录，用于跟踪和管理版本库。

添加文件/add

git add

. 自动添加本地所有修改。

提交/commit

git commit

$-m$ 增加提交信息。
$-a$ 自动寻找修改的文件并提交。

状态查看/status

git status

$-s$ 简短输出。

改动查看/diff&blame

git diff

$–cached$ 显示暂存区的改动。
$HEAD$ 查看所有改动。
$–stat$ 显示摘要。

git blame

文件修改记录。

历史查看/log

git log

按时间由近到远排序，列出最近的三次提交。
$-p\ \ [filename]$ 文件最后一次提交信息。
$–pretty=oneline$ 可以列出简略的信息。
$–graph$ 拓扑图显示。
$–reverse$ 逆向显示。
$–author=$ 查找指定作者。
$–since$, $–before$, $–util$, $–after$ 指定日期。
$–decorate$ 显示标签。

提交撤销/revert

git revert

回退版本/reset

git reset --hard HEAD^
git reset --hard HEAD~2
git reset --hard 56e7

$HEAD$ 表示当前版本。^ 表示回退一个版本，可以输入多个 ^。$\sim$ 之后可以输入任意数字，表示回退对应数量的版本。也可以直接输入版本号，版本号通过 $git\ \ log$ 命令查询，使用版本号不仅可以回退版本，在错误回退版本之后，也可以前进到指定的版本，版本号可以不写全，但一定要写到Git能识别出唯一一个版本为止。

JWT简介

Tue, 04 Aug 2020 16:41:22 +0800

JWT-Wikipedia

JWT( $JSON\ \ Web\ \ Token$ )是一种基于JSON的用于创建可选签名或可选加密的数据的互联网标准。Token使用一个私钥或者公钥进行签名，持有私钥或者公钥的一方可以验证令牌的合法性。Token被设计为紧凑且安全的，尤其适用于Web浏览器单点登录 ( Single-sign-on, $SSO$ ) 场景。JWT声明一般用于在身份提供者和服务提供者之间传递用户身份信息，或者用于业务流程要求的任何其他类型的声明。

设计模式

Fri, 10 Jul 2020 16:57:11 +0000

设计模式常用的七大原则：

单一职责原则——一个类应该只负责一项职责。
接口隔离原则——一个类对应另一个类的依赖应该建立在最小的接口上。
依赖倒转原则
1. 高层模块不应依赖于低层模块
2. 抽象不应该依赖于细节
3. 面向接口编程（中心思想）
里氏替换原则——所有引用基类的地方必须能透明的使用子类。
开闭原则——软件实体对扩展开放，对修改关闭，用抽象构建框架，用实现扩展细节。
迪米特法则——一个类应该将逻辑封装在内部，不对外泄露。
合成复用原则——尽量使用合成/聚合方式

23种设计模式的三种类型：

创建型模式：单例模式、抽象工厂模式、原型模式、建造者模式、工厂模式；
结构型模式：适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式；
行为型模式：模板方法模式、命令模式、访问者模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式、状态模式、策略模式、职责链模式（责任链模式）。

1.单例模式

单例模式，即采取一定的方法保证在整个软件系统中，对某个类只能存在一个对象实例，并且该类只提供一个取得其对象实例的方法（通常为静态方法）。单例模式有八种方式：

饿汉式（静态常量）
饿汉式（静态代码块）
懒汉式（线程不安全）
懒汉式（线程安全，同步方法）
懒汉式（线程安全，同步代码块）
双重检查
静态内部类
枚举

1.1 饿汉式（静态常量）

构造器私有化（即不能通过 $new$ 创建实例）
类内部创建对象
向外暴露一个静态公共方法
代码实现

class Singleton {
  private final static Singleton instance = new Singleton();

  private Singleton() {
  }

  public static Singleton getInstance() {
    return instance;
  }
}

优点：写法简单，在类装载时实例化，避免了线程同步问题。
缺点：不是懒加载，可能存在内存资源的浪费。

1.2 饿汉式（静态代码块）

构造器私有化
类内部声明私有静态成员
静态代码块内实例化
$getInstance$ 公共静态方法实现

class Singleton2 {
  private static Singleton2 instance;

  static {
    instance = new Singleton2();
  }

  private Singleton2() {}

  public static Singleton2 getInstance() {
    return instance;
  }
}

优缺点同上。

数据库系统（9）：事务管理

Sat, 13 Jun 2020 17:55:26 +0000

DBMS应该具备的功能中，有三个密切相关的功能，用以保证数据库的可靠性和一致性，即事务支持、并发控制服务和恢复服务。它们之间是相互依赖的。并发控制和恢复主要用于保护数据库，避免数据库发生数据不一致或者数据丢失。许多DBMS都允许用户对数据库进行并发操作。如果对这些操作不加控制，对数据库的访问将互相干扰，使得数据库出现不一致的情况。为了解决这个问题，DBMS实现了并发控制 ( $concurrency\ \ control$ ) 协议，来阻止数据库访问之间的相互干扰。数据库恢复 ( $Database\ \ recovery$ ) 是指在故障以后将数据库还原到正确状态的过程。

1. 支持事务处理

        事务 ( $Transaction$ ) 是由单个用户或者应用程序执行的，完成读取或者更新数据库内容的一个或者一串操作。事务是数据库的逻辑操作单位 ( $logical\ \ unit\ \ of\ \ work$ ) 。它可以是整个程序、部分程序或者一条命令，也可以是涉及数据库的任意多个操作。从数据库的角度来看，应用程序的一次执行就是一个事务或者多个事务，若看成多个事务，在事务与事务之间只会出现非数据库操作。复杂的事务由很多操作构成。若并非所有操作都被执行，那么可能会出现不一致状态 ( $inconsistent\ \ state$ ) 。在事务处理过程中，尽管我们允许数据库的一致性遭到暂时破坏，但是事务应该总是能将数据库从一种一致的状态转移到另一种一致的状态。
        事务可能有以下两种结果中的一种。如果执行成功，也就是说事务最终被提交 ( $committed$ )，数据库也将到达一种新的一致状态。另一种情况下，事务没有执行成功，则会被撤销 ( $aborted$ )。如果事务被撤销，则数据库必须要还原到事务开始之前的一致的状态。我们称这样的事务被回滚 ( $rolled\ \ back$ ) /撤销 ( $undone$ )。已经提交的事务无法撤销。如果发现已提交的事务存在错误，必须执行另一个补偿事务 ( $compensating\ \ transaction$ ) 来消除该事务已经产生的影响。
        DBMS无法得知哪些更新操作将被组合在一起以构成一个独立的逻辑事务。因此很多数据操作语言中都使用关键字 $BEGIN$, $TRANSACTION$, $COMMIT$, $ROLLBACK$ 来划定界限。如果不使用，通常会将整个程序视为一个事务。

1.1 事务的性质

原子性 ( $Atomicity$ )：事务是一个不可分割的单元，要么全执行，要么全不执行。事务的原子性由DBMS的恢复子系统负责保证。
一致性 ( $Consistency$ )：事务必须将数据库从一种一致的状态转换到另一种一致的状态。事务的一致性是由DBMS和应用程序的开发者共同保证的。DBMS可以通过强制实施所有在数据库模式中定义的约束（如完整性约束和企业自定义约束）来保证一致性。
隔离性 ( $Isolation$ )：事务的执行是相互独立的，即未完成事务的中间结果对其他事务来说应该是不可见的。事务的隔离性由并发控制子系统负责保证。
持久性 ( $Durability$ )：成功完成的事务的结果要永久地记录在数据库中。事务的持久性由恢复子系统负责保证。

1.2 数据库体系结构

数据库系统（8）：规范化

Fri, 22 May 2020 16:13:29 +0000

规范化 ( $Normalization$ ) 是一种数据库设计技术，从分析属性之间的联系入手。规范化使用一系列测试，描述为范式 ( $normal\ \ forms$ ) 帮助我们确定这些属性的最佳组合，最终生成一组适当关系。

1. 目的

规范化的目的是确定一组合适的关系以支持企业的数据需求。该关系具有以下性质：

属性的个数最少，且是必需的
具有紧密逻辑联系，描述为函数依赖 ( $functional\ \ dependency$ ) 的所有属性均在一个关系中
最少的冗余，即每个属性仅出现一次，除了作为外键的属性，因为连接相关关系必须用到外键

具有一组合适的关系，数据库会易于用户访问，数据易于维护，在计算机上也会占有较小的存储空间。

2. 支持

规范化有两种使用方法。方法 $1$ 将规范化视为一种自下而上 ( $bottom-up$ ) 的独立的数据库设计技术。方法 $2$ 将规范化作为一种确认技术使用，即用规范化检验关系的结构，而这些关系的建立可能采用自上而下的方法，如ER建模等。

3. 数据冗余与更新异常

关系数据库设计的一个目的就是将属性组合成关系时保证最少的数据冗余。当然，关系数据库的运行也依赖于一定的数据冗余的存在，一般是以主键或者候选键的多个副本的形式出现，作为外键表示数据间联系。存在冗余数据的关系可能存在一些问题，如更新异常 ( $update\ \ anomalies$ )。更新异常又可分为插入异常、删除异常和修改异常。

$Staff$ 和 $Branch$ 是不存在数据冗余的两个表。$StaffBranch$ 是将上两个表合起来的存在数据冗余的表，同一个分公司的信息会重复出现。

3.1 插入异常

插入异常主要有两类：

在向 $StaffBranch$ 中插入新员工时，若同一家分公司信息不同，则会产生一致性问题；
在向 $StaffBranch$ 中插入新的分公司时，由于没有员工，因此员工信息都应设为 $null$ 。但是主键 $staffNo$ 不能为空，否则会违反实体完整性约束。

3.2 删除异常

从 $StaffBranch$ 中删除元组时，若该元组中的员工信息是某个分公司的最后的员工，则该分公司的信息也会被删除。

3.3 修改异常

当要修改 $StaffBranch$ 中某个分公司的属性值时，必须依次修改所有包含该分公司信息的元组。

数据库系统（7）：ER模型

Thu, 21 May 2020 15:51:36 +0000

ER模型是一种自上而下 ( $top-down$ ) 的数据库设计方法，该方法首先确定那些被称为实体的重要数据和这些数据之间的联系，实体和联系时ER模式中必备的元素。然后添加更多的细节信息，如属性、约束等。
统一建模语言 ( $Unified\ \ Modeling\ \ Language$, $UML$ ) 是软件工程项目的工业标准建模语言，我们使用UML的符号集来绘制ER模型。

1 实体类型

实体类型 ( $Entity\ \ types$ ) 是被企事业单位认可的、能够独立存在的一组具有相同属性的对象，是ER模型的基本概念。实体类型既可以是物理 ( 真实 ) 存在的，也可以是概念 ( 抽象 ) 存在的对象。实体出现 ( $entity\ \ occurrence$ ) 是实体类型中可唯一标识的一个对象。在没有歧义的时候，实体类型和实体出现都可以直接简称为实体。
在UML中，实体类型通过一个标有名字的矩形标识，每个实体名字的首字母是大写的。

2. 联系类型

联系类型 ( $Relationship\ \ types$ ) 是实体类型间一组有意义的关联。每个联系类型都被赋予一个能够描述其功能的名字。联系出现 ( $Relationship\ \ occurrence$ ) 是由参与该联系的各个实体类型的一个出现组成的可被唯一标识的关联。
在UML中，每个联系类型都表现为用线将相关的实体类型联系起来，并在线上标上联系的名字，通常使用一个动词或者动词短语命名。同样的，首字母也应该大写。一个联系还要标识方向，意味着这个联系仅在一个方向上有意义。可以在名字旁边添加一个箭头符号，如 $\blacktriangleleft$ 来标识方向。当我们要表示 $A\ \ Has\ \ B$ ( $A$，$B$ 为实体，$Has$ 为联系类型 ) 时可以用如下方法：

数据库系统（6）：SQL数据定义

Wed, 20 May 2020 16:46:30 +0000

1. 数据类型

1.1 标识符

SQL标识符 ( $identifier$ ) 用于表示数据库中的对象，如表名、列名、视图名等。用户定义标识符所用的字符必须是字符集 ( $character\ \ set$ ) 中存在的。默认的字符集包括 $A-Z$, $a-z$ 和 $_$ ，也可以另外指定其他字符集。标识符的限制有：

不能长于 $128$ 个字符（在一些方言中会更短）
必须以字母开头
不能有空格

1.2 数据类型

数据类型	声明
布尔型	$BOOLEAN$
字符型	$CHAR$, $VARCHAR$
位类型	$BIT$, $BIT\ \ VARYING$
定点数型	$NUMERIC$, $DECIMAL$, $INTEGER$, $SMALLINT$, $BIGINT$
浮点数型	$FLOAT$, $REAL$, $DOUBLE\ \ PRECISION$
日期时间型	$DATE$, $TIME$, $TIMESTAMP$
间隔型	$INTERVAL$
大对象型	$CHARACTER\ \ LARGE\ \ OBJECT$, $BINARY\ \ LARGE\ \ OBJECT$

1.2.1 布尔型

布尔型包括 $TRUE$ / $FALSE$ 两个值，如果没有 $NOT\ \ NULL$ 约束，也可以为 $NULL$ 。$TRUE$ 大于 $FALSE$ ，对于涉及 $NULL$ 的比较，结果都是 $UNKNOWN$ 。

数据库系统（5）：SQL数据操作

Wed, 20 May 2020 14:17:14 +0000

1. `SQL`简介

SQL是关系模型发展过程中出现的一种特殊语言，已经成为了标准的关系数据库语言。SQL是面向转换语言 ( $transform-oriented\ \ language$ ) 的例子，将输入关系转换为所需的输出关系，包括两个主要部分：DML和DDL。
SQL具有许多实现版本，每个实现称为方言 ( $dialect$ ) ，供应商在标准之外提供的特性称为扩展 ( $extensions$ )。

1.1 优点

满足数据库语言的思想
易于学习
结构简洁、轻便
存在SQL标准
可以通过终端或者嵌入式访问
所有人都可以使用

1.2 缺点

混合了编程规范和嵌入式访问
缺乏正交性，有多种表达方式
语言越来越复杂和庞大
聚合函数中对空的处理问题
结果表中可以有重复元组，对表中的行和列都强加了一个顺序

2. `SQL`命令

SQL语言包括保留字 ( $reserved\ \ words$ ) 和用户自定义字 ( $user-defined\ \ words$ ) 。保留字是SQL语言的固定部分，有固定含义。用户自定义字由用户定义，用于表示表、列、视图和索引等数据库对象的名称。虽然标准并没有要求，但是SQL的许多实现版本要求用句子终结符来表示SQL语句的结束。SQL语句的多数组成部分是不区分大小写的，除了字符数据常量外。

2.1 数据操作

DML语句有以下几种：

$SELECT$,
$INSERT$,
$UPDATE$,
$DELETE$.

常量 ( $Literals$ ) 是指SQL语句中的不变量 ( $constants$ )。不同的数据具有不同的常量形式，所有的非数值型数据必须使用引号，而所有的非数值型数据不能使用引号。

2.2 查询

查询形式：

SELECT [DISTINCT|ALL] {*|[columnExpression [AS newName]][...]}
FROM TableName [alias][...]
[WHERE condition]
[GROUP BY coulumnList]
[HAVING condition]
[ORDER BY columnList]

处理顺序：

数据库系统（4）：关系代数

Sun, 17 May 2020 16:05:13 +0000

关系代数 ( $Relational\ \ Algebra$ ) 可以看成一种过程式语言，可用于构造新关系。关系代数是一种纯理论语言，它定义了一些操作，运用这些操作可以从一个或多个关系中得到另一个关系而不改变原关系。关系代数的一个表达式可以嵌套另一个表达式，这种性质称为闭包 ( $closure$ )，即关系在关系代数下是封闭的。
关系代数是一种每次一关系/集合的语言，即用一条不带循环的语句处理，结果也是由所有元组组成的整个关系。关系代数中包含了许多运算，其中五个基本运算是选择 ( $Selection$ ) 、投影 ( $Projection$ ) 、笛卡尔乘积 ( $Cartesian\ \ product$ ) 、集合并 ( $Union$ ) 、集合差 ( $Set\ \ difference$ ) 。选择和投影都是一元运算，其他的运算则是二元运算。除此之外，还有连接 ( $Join$ ) 、集合交 ( $Intersection$ ) 、除 ( $Division$ ) 等，它们都能通过五个基本运算表示。

1. 一元运算

1.1 选择

$$ \sigma_{predicate}(R) $$

作用于单个关系 $R$ ，得到一个新关系，该关系由满足谓词 $predicate$ 的元组组成。可以理解为从表中选出符合条件的行构成一个新表。

1.2 投影

$$ \prod\nolimits_{a_1,a_2,...,a_n}(R) $$

作用于单个关系 $R$ ，得到一个由 $R$ 的垂直子集构成的新关系，该子集抽取 $R$ 中指定属性上的值并去掉重复元组。可以理解为从表中选出指定的列构成一个新表。

数据库系统（3）：关系模型

Fri, 15 May 2020 13:08:11 +0000

在目前使用的数据处理软件中，关系数据库管理系统 ( $Relational\ \ Database\ \ Management\ \ System$, $RDBMS$ ) 占据了统治地位。RDBMS基于关系数据模型。在关系模型中，所有数据逻辑上被组织成关系（表）结构。

1. 基本术语

关系模型基于数学中的关系 ( $relation$ )。

1.1 关系数据结构

1.1.1 关系

关系是由行和列组成的表。在关系模型中，用关系保存数据库所描述对象的信息，关系用二维表表示。用户主要接触的就是表，但这只限于逻辑结构，即外部层和概念层。对于物理结构，由于是通过多种存储结构实现的，因此并不适用。

1.1.2 属性

属性 ( $Attribute$ ) 是关系中命名的列。在关系的二维表中，每一行对应一个单独的记录，每一列则对应一个属性。

1.1.3 域

域 ( $Domain$ ) 是一个或多个属性的取值集合，必须给每一个属性定义一个域。不同属性的域可以互不相同，也可以共用。通过使用域，用户可以集中定义属性的取值范围和含义。

1.1.4 元组

元组 ( $Tuple$ ) 是关系中的行。关系的结构、域说明以及所有取值约束统称为关系的内涵 ( $intension$ )。它通常是固定的，除非关系的意义改变，需要加入新的属性。元组的集合称为外延 ( $extension$ ) /状态 ( $state$ )，它经常发生改变。

1.1.5 维数

维数 ( $Degree$ ) 是关系所包含的属性个数。只有一个属性的关系称为一元关系或者一元组，两个属性的关系称为二元关系，以此类推，$n$ 个属性的关系称为 $n$ 元组。维数是内含的性质之一。

1.1.6 基数

基数 ( $Cardinality$ ) 是关系所包含的元组的个数。基数是外延的性质之一。

数据库系统（2）：数据库环境

Thu, 14 May 2020 11:09:00 +0000

1. `ANSI-SPARC`三层体系结构

三层体系结构 ( $Three\ \ Level\ \ Architecture$ )，包括外部层 ( $External$ )、概念层 ( $Conceptual$ ) 和内部层 ( $Internal$ )。用户从外部层观察数据，DBMS和操作系统从内部层观察数据。在内部层，数据使用定义的数据结构和文件组织方法进行存储。概念层则提供内部层和外部层的映射 ( $Mapping$ ) 以及必要的独立性 ( $Independence$ )。三层体系结构的目的是将用户的数据库视图与数据库的物理描述分离。

1.1 外部层

外部层是数据库的用户视图，这一层描述数据库中与用户相关的部分。对于每一个用户，数据库中都存储着其对用的视图。并且对于同一个数据，在不同的视图中可能有着不同的表达方式。

1.2 概念层

概念层是数据库的整体视图，这一层描述哪些数据存储在数据库中，以及这些数据之间的联系。概念层描述：

所有的实体、实体的属性和实体间的联系
数据的约束
数据的语义信息
安全性和完整性信息

概念层支持每一个外部视图，凡是用户可访问的数据必定包含在概念层或者由概念层导出。

1.3 内部层

内部层是数据库在计算机上的物理表示，这一层描述数据是如何存储在数据库中的。内部层与如下工作相关：

数据和索引的存储空间分配
存储记录的描述
存储记录
数据压缩和加密

在内部层之下是物理层 ( $Physical\ \ Level$ ) ，物理层可能在DBMS的指导下受操作系统的控制。

1.4 模式、映射和实例

        对数据库的整体描述称为数据库模式 ( $Database\ \ Schema$ ) 。在数据库中存在三种不同类型的，在外部层有若干外部模式 ( $External\ \ Schema$ ) /子模式 ( $Subschema$ )，与不同的数据视图对应。在概念层有概念模式 ( $Conceptual\ \ Schema$ )，描述所有实体、属性和联系及其之间的完整性约束。在内部层，有内部模式 ( $Internal\ \ Schema$ )，是内部模型的完整描述，包括存储记录的定义、表示方法、数据域，必要时还有所使用的索引和散列方案。一个数据库可以有多个外部模式，但只能有一个概念模式和内部模式。
        例如，对于一个数据库，其内部存储两张表 $A$, $B$ ，这是其概念模式；而 $A$, $B$ 内部行列的定义以及约束等是其内部模式；查询 $A$, $B$ 所使用的视图 $V1$, $V2…$ 是其外部模式。
        DBMS负责着三类模式之间的映射。概念模式通过概念层到内部层的映射与内部模式关联，每一个外部模式通过外部层到概念层的映射与概念模式关联。
        数据库模式是在数据库设计过程中定义的，不会轻易改变。数据库中的数据是一个数据库实例 ( $Database\ \ Instance$ )，许多数据库实例可以与相同的数据库模式对应。模式有时称为数据库的内含 ( $Intension$ )，实例称为数据库的外延 ( $Extension$ ) /状态 ( $State$ )。

数据库系统（1）：数据库简介

Wed, 13 May 2020 14:23:36 +0000

1. 基于文件的系统

基于文件的系统 ( $Traditional\ \ File-Based\ \ Systems$ ) 是一组为终端用户提供服务的应用程序，每一个程序定义和管理它自己的数据。相较于使用纸质文件进行管理的手工文件系统，基于文件的系统更加高效。但是它未能集中存储组织机构的运行数据，而是采用了分散的方法，即每一个部门在数据处理 ( $DP$ ) 人员的帮助下存储和控制它们的数据。通过编写应用程序来管理和查询数据，具有程序-数据依赖性 ( $Program-data\ \ Dependence$ ) 。

1.1 术语

文件 ( $File$ ) 是一些记录 ( $Records$ ) 的简单集合，这些记录中包含逻辑上相关的数据。每一条记录包含一组逻辑上相关的一个或多个数据项/域 ( $Fields$ ) 。

1.2 局限性

数据被分离和孤立
数据被孤立在分离的文件中，如果要访问处于不同文件之间的数据，需要创建一个临时文件。
数据存在冗余
由于文件间的分离，有时需要重复记录一些数据。
数据存在依赖性
数据文件的物理结构和存储方式是由应用程序定义的，很难做出改变，也即程序-数据依赖性。
文件格式不相容
文件结构嵌入应用程序，因此由应用程序语言决定。难以兼容其他使用不同语言的文件结构。
需要不断更改应用程序
完全依赖于开发人员，要求开发人员以编程方式实现所有查询和表。如果查询需求发生了变化，需要重新编写程序或更改文件。

2. 数据库方法

基于文件的系统存在许多问题，总结原因是：

数据内嵌应用程序
无法实现程序规定之外的操作

因此我们需要一种更加高效的方法，数据库 ( $Database$ ) 和 数据库管理系统 ( $Database\ \ Management\ \ System,\ \ DBMS$ ) 应运而生。

2.1 数据库

数据库是为满足某个组织机构的信息要求而设计的一个逻辑相关数据及其描述的共享集合。在数据库内，所有的数据项都被集中起来，具有很少的冗余，为所有部门共享的资源。在其内部不仅含有组织的运行数据，还含有对这些数据的描述。因此，有时数据库也被定义为一组集成记录的自描述的集合。

Redis笔记

Sun, 10 May 2020 17:20:42 +0000

1. `Redis`简介

NoSQL即 $Not-Only\ \ SQL$ ，是RDBMS的补充。
Redis是一种NoSQL数据库，是一个使用C语言开发的开源的高性能键值对数据库，内部使用单线程机制进行工作。

$set\ \ [key]\ \ [value]$ 添加信息,
$get\ \ [key]$ 查询信息，为空返回 $nil$ ,
$del\ \ [key]$ 删除信息，$1$ 代表删除成功,
$clear$ 清屏,
$help\ \ [op]$ 帮助,
$time$ 获取时间.

2. 数据类型

Redis采用键值对的方式存储，$key$ 为字符串，$value$ 则允许多种类型。

2.1 `string`

最简单的数据类型，最大存储量 $512MB$ ，可以作为数字使用，最大值为 $java.lang.Long$ 类型的最大值，允许以JSON对象的方式存储数据，值中间不能有空白符

$mset/mget$ 获取多个数据
$strlen$ 获取字符个数
$append$ 追加，返回总长度，也可以用于添加信息
$incr/incrby/incrbyfloat$ 指定数据增加指定值，允许负数，返回数值
$decr/decrby$ 指定数据减少指定的值，允许负数，返回数值
$setex/psetex$ 设定数据周期，秒/毫秒

2.2 `hash`

hash 属于 $value$ ，其中包含多组键值对，键称为 $field$ ，键值对较少时为类数组结构，较多时为 $HashMap$ 结构，$value$ 只能为 string ，且最多只能有 $2^{32} - 1$ 组。

JavaWeb（4）：Spring简介

Tue, 21 Apr 2020 15:48:49 +0000

参考书籍：《Pro Java for Web Apps》

Maven依赖

<dependency>
    <groupId>javax.inject</groupId>
    <artifactId>javax.inject</artifactId>
    <version>1</version>
    <scope>compile</scope>
</dependency>

<dependency>
    <groupId>javax.annotation</groupId>
    <artifactId>javax.annotation-api</artifactId>
    <version>1.3.2</version>
    <scope>runtime</scope>
</dependency>

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-webmvc</artifactId>
    <version>5.2.4.RELEASE</version>
    <scope>compile</scope>
</dependency>

        Spring Framework是一个Java应用程序容器，它提供了许多有用的特性，如反转控制（IoC）、依赖注入（DI）、抽象数据访问、事务管理等。
        IoC是一个软件设计模式，即组装器（Spring Framework)在运行时才会绑定对象，也就是运行时才会实例化依赖的组件。这使得开发者可以针对接口进行编程，无需重新编译代码。DI是IoC的一种实现方式，通过DI，一个类可以通过声明其依赖的接口类型，然后利用组装器在运行时注入其依赖的实例。
        Spring Framework提供了一个MVC（模型-视图-控制）模式框架，利用它可以简化创建Web应用程序的过程，不用手动处理复杂的Servlet、HttpServletRequest等。控制器类的每个方法都被映射到了一个不同的请求URL、方法或请求的其他属性上，模型可以通过 $Map$<$String, Object$>的形式从控制器传递到视图，控制器返回的视图或视图名称将把模型转发到合适的JSP视图。通过这些特性，Spring Framework极大地简化了Servlet容器的工作内容。
        使用MVC框架时，控制器类中的每个方法都可以拥有一个指向特定URL、请求方法、参数存在性、头的值、内容类型或期望响应类型的唯一映射。
        Spring Framework容器以一个或多个应用上下文的形式存在，由 $org.springframework.context.ApplicationContext$ 接口表示。一个应用上下文管理着一组bean、执行业务逻辑的Java对象、执行任务等。由Spring管理的bean可以自动进行DI、消息通知、bean验证等服务。一个Spring程序至少需要一个应用上下文，也可以使用多个应用上下文组成层次结构。在层次结构中应用上下文间有着类似于树的父子兄弟关系，一个子应用上下文的bean可以访问父应用上下文的bean，但无法访问兄弟应用上下文的bean。许多类都继承了 $ApplicationContext$ ，也有许多实现了它：

类	描述
$ConfigurableApplication$	可配置的应用上下文
$WebApplicationContext$	用于`Java EE Web`应用程序，提供了对 $ServletContext$ 和 $ServletConfig$ 的访问
$ConfigurableWebApplicationContext$	可配置的 $WebApplicationContext$
$XmlApplicationContext$	用于在`Java EE Web`应用程序中从`XML`文件加载`Spring`配置
$AnnotationConfigWebApplicationContext$	用于在`Java EE Web`应用程序中以编程方式配置`Spring`

Spring使用 $DispatcherServlet$ 处理Web请求，该Servlet将请求委托给合适的控制器，并按需求对请求和响应实体进行转换。在Web应用程序中，我们可以使用任意数量的 $DispatcherServlet$ 。每个 $DispatcherServlet$ 类都有自己的应用上下文，包含了对Web应用程序的 $ServletContext$ 和自己的 $ServletConfig$ 的引用。

使用WebSocket实现的一个简单的多人聊天室

Sun, 19 Apr 2020 17:25:57 +0000

环境：JDK1.8, tomcat-8.5.51
源码可以在GitHub上查阅：ChatRoom

WebSocket最常用的地方就是聊天室，所以我用Servlet+WebSocket实现了一个简单的多人聊天室。这个多人聊天室改一改就能作为一对一的聊天室使用，毕竟实现方法都是差不多的。

首先是maven依赖，在此只展示几个要注意的依赖项：

<dependencies>
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <version>1.18.12</version>
            <scope>provided</scope>
        </dependency>

        ......
        ......

        <dependency>
            <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-databind</artifactId>
            <version>2.10.0</version>
            <scope>compile</scope>
        </dependency>

        <dependency>
            <groupId>com.fasterxml.jackson.datatype</groupId>
            <artifactId>jackson-datatype-jsr310</artifactId>
            <version>2.10.0</version>
            <scope>compile</scope>
        </dependency>

    </dependencies>

Lombok简化实体的编写（虽然只有一个实体），然后jackson相关的依赖用于Java实例和JSON对象之间的相互转化。为了避免兼容问题，我这里选择依赖基本上都是最新版本。
然后是实体，$ChatMessage$ 用于存储消息相关的信息，使用lombok简化了编写：

import lombok.AllArgsConstructor;
import lombok.Getter;
import lombok.NoArgsConstructor;
import lombok.Setter;

import java.time.OffsetDateTime;

@Getter
@Setter
@AllArgsConstructor
@NoArgsConstructor
public class ChatMessage {
  private String username;
  private String message;
  private OffsetDateTime timestamp;
}

有了实体之后再建立仓库，用于存储聊天信息以及用户信息：

JSON序列化传输过程中中文乱码问题的解决方法

Sat, 18 Apr 2020 22:13:49 +0000

今天在用WebSocket和Servlet写聊天室的时候发现传输中文会乱码的问题，起初以为是在用jackson的 $ObjectMapper$ 将对象转化为字节流的时候出现的问题，但是经过检查后发现不是。又检查了一遍编码，确认了网页的编码是utf-8，输入的字符串也是utf-8，然后发现问题是出在了JSON对象传输的过程中。最后在 stackoverflow 上找到了解法。

我的问题出在将经过JSON序列化之后的消息对象字符串转换为 $Uint8Array$ 以及将 $Uint8Array$ 转为消息对象的过程中，对此可以采用 $TextEncoder$ 和 $TextDecoder$ 对象。如下所示：

let encoder = new TextEncoder('utf-8');
let decoder = new TextDecoder('utf-8');
let message = {
    username: '用户',
    content: '你好，世界！'
};

let array = encoder.encode(JSON.stringify(message));
let newMessage = JSON.parse(decoder.decode(array));

在上例中，我们分别使用 $TextEncoder$ 和 $TextDecoder$ 以utf-8作为编码方式创建了编码器和译码器，之后声明了一个 $message$ 对象存储我们要传递的消息，使用JSON序列化该对象，并使用编码器进行编码，编码后得到的是可以进行传输的 $Uint8Array$ 对象，而对其使用译码器进行译码可以得到另一个 $newMessage$ 对象，该对象内存储的值与之前的 $message$ 相同，并且没有出现中文乱码的现象。

JavaWeb（3）：WebSocket简介

Mon, 06 Apr 2020 14:57:01 +0000

参考书籍：《Pro Java for Web Apps》

        WebSocket用于解决浏览器和服务器的通信问题。在现有体系中，如果只是简单的使用Ajax进行通信的话，容易出现的问题是只有浏览器发送请求时才能得到响应。也即当有新数据时，浏览器不能得知新数据的存在，也就不能及时发送请求获取新数据。
        WebSocket使用了HTTP/1.1 升级特性。该特性的使用很简单，只需要在请求中包含头名称和值 $Connection: Upgrade$ ，并在额外的 $Upgrade$ 头中指定一个或多个协议的列表。如果服务器接收升级请求，那么将返回 $101\ \ Switching\ \ Protocols$ 。HTTP升级提供的最重要的特性是我们可以使用任意协议，并且在升级完成后就不再使用HTTP连接，我们可以用一个Socket来代替，由此产生了WebSocket协议。WebSocket协议将使用心跳消息（分别称为 $ping$ 和 $pong$ ）保持连接活跃，即周期性地发送小数据包。在连接升级为WebScoket协议之后，文本和二进制消息可以持续在两个方向上发送且不需要关闭和重连了；而且HTTP规范要求对应同一个主机名，只允许有两个并发连接，但由于我们升级为WebScoket连接了，因此该规范也不存在了。
        使用WebSocket协议之前需先以HTTP协议向服务器发送特殊请求，访问一个特殊的URL，该URL以ws或者wss开头，分别对应http和https，并且除了 $Connection: Upgrade$ 头之外，还包含一个 $Connection: websocket$ 头，用于指定服务器将连接升级为 WebSocket协议。

HTML5(JavaScript)客户端API

WebSocket并不是只能用于浏览器和服务器的通信中，理论上可以将其应用于任何支持其的应用程序中。但如果要编写使用WebSocket进行连接的浏览器客户端终端，我们就要用到JavaScript，尽管我们使用JavaScript编写，但实际上WebSocket是HTML5的一部分。使用JavaScript创建WebSocket对象十分简单：

var connection = new WebSocket('ws://www.example.com/chat', {'chat.v1', 'chat.v2'});

WebSocket构造函数第一个参数为连接所使用的URL，第二个参数可选，为连接所使用的一个或多个协议，这些协议都是自己创建的，不受WebSocket管理。
WebSocket接口中包含 $readyState$ 属性表示当前状态，值为 $CONNECTING$, $OPEN$, $CLOSING$, $CLOSED$ 中的一个，包含四个事件：$onopen$, $onclose$, $onerror$, $onmessage$ ，前两者分别在 $readyState$ 由 $CLOSING$ 变为 $CLOSED$ 时和 $readyState$ 由 $CONNECTING$ 变为 $OPEN$ 时触发。传入 $onclose$ 方法的事件包含三个属性：$wasClean$, $code$, $reason$ ，传入 $onopen$ 的是普通的事件，传入 $onerror$ 和 $onmessage$ 的事件包含一个 $data$ 属性，在前者中是错误对象，而在后者则根据消息类型转变：消息为字符串，则 $data$ 也为字符串；消息为二进制数据，并且 $WebSocket.binaryType$ 将被默认设置为 $blob$ 时，$data$ 为 $Blob$ ，而 $WebSocket.binaryType$ 为 $arraybuffer$ 时，$data$ 为 $ArrayBuffer$ 。通常我们应该在实例化之后立即设置 $bianryType$ 的值。WebSocket对象的 $send$ 方法接收 $string$, $Blob$, $ArrayBuffer$, $ArrayBufferView$ 中一个类型的参数，表示要传输的数据；并且在该方法的作用域内我们还可以使用 $WebSocket.bufferedAmount$ 属性，该属性的值为之前的 $send$ 调用还有多少需要传输到服务器的数据。WebSocket的 $close$ 用于关闭连接，接收两个可选参数，第一个为关闭代码（默认为 $1000$ ），第二个为字符串，表示原因。

JavaWeb（2）：Session简介

Thu, 26 Mar 2020 15:41:52 +0000

参考书籍：《Pro Java for Web Apps》
注：演示所用 Java 版本为 Java8 ，所用容器为 Tomcat8.5.51

        会话用于处理维持请求和请求之间的状态。在没有使用会话时，HTTP请求是无状态的，在浏览器打开第一个连接到服务器的套接字时开启，在服务器返回最后一个数据包时结束。而有些时候，我们希望保持状态，如用户登录或者在线编辑时，这时我们就要用到会话。
        在Web中，会话是由服务器或Web应用程序管理的某些文件、内存片段、对象或者容器。服务器在第一次接收到请求时，会随机生成一串字符串，称为会话ID，并返回用户浏览器中。之后所有从该用户浏览器中发出的请求都需要包含该会话ID，服务器接收到会话ID后可以将会话与请求关联起来。HTTP cookie用于将会话ID发送到服务器，但是如果用户浏览器禁止了cookie，那么就需要将会话ID内嵌在URL中，很明显，这种方式使得其他人可以轻松地获得会话，因此是不安全的。不过由于如今许多网站都要求用户在访问时启用cookie，因此我们可以不用顾虑这点。
        会话也是有漏洞的。但是由于描述起来篇幅过长，因此不做赘述，如果感兴趣的话可以在 Session hijacking -Wikipedia 中查看。

大部分情况下我们可以直接使用会话，不需要添加显式配置，但是出于安全目的，我们应该进行配置。使用<$session-config$>标签进行配置，同时在<$session-config$>标签内，我们也可以使用<$cookie-config$>标签进行cookie的配置。所有在<$session-config$>标签和<$cookie-config$>标签内的标签都是可选的。下面列出了所有的可选标签：

<session-config>
    <session-timeout>30</session-timeout>
    <cookie-config>
        <name>JSESSIONID</name>
        <domain>example.org</domain>
        <path>/path</path>
        <comment><! [CDATA[Keeps you logged in. See our privacy policy for more information.]]></comment>
        <http-only>true</http-only>
        <secure>false</secure>
        <max-age>180</max-age>
    </cookie-config>
    <tracking-mode>COOKIE</tracking-mode>
    <tracking-mode>URL</tracking-mode>
    <tracking-mode>SSL</tracking-mode>
</session-config>

下面为每个标签的作用：

标签	作用
<$session-timeout$>	会话在无效前可以保持不活跃状态的时间，以分钟为单位，为 $0$ 表示永远不过期。
<$tracking-mode$>	表示容器使用哪种技术追踪会话ID，可以配置多个值，按照配置顺序使用。`URL`表示容器将在`URL`中内嵌会话ID，`COOKIE`表示使用`cookie`，`SSL`表示使用`SSL`会话，但要求所有请求均是`HTTPS`请求。
<$name$>	可以自定义会话`cookie`的名字，通常不用设置。
<$domain$>	设置`cookie`的`Domain`特性，通常不用设置。
<$path$>	设置`cookie`的`Path`特性，通常不用设置。
<$comment$>	可以添加任意文本，用于解释`cookie`。
<$http-only$>	设置`cookie`的`HttpOnly`特性，为了提高安全性，一般都设置为 $true$ 。
<$secure$>	设置`cookie`的`Secure`特性，如果使用的是`HTTPS`，就应设置为 $true$ 。
<$max-age$>	设置`cookie`的`Max-Age`特性，控制`cookie`何时过期，以秒为单位，通常不用设置。

学习了如何配置会话之后，就该学习如何使用会话了。为了获取会话，我们可以调用 $HttpServletRequest.getSession(\ )$ 方法。该方法不接受或者接受一个 $boolean$ 类型的参数。无参或者传入 $true$ 时会在没有会话时创建会话，传入 $false$ 则不会创建。调用该方法后我们就得到了一个 $javax.servlet.http.HttpSession$ 类型。对于该对象，常用方法如下：

JavaWeb（1）：Servlet入门

Sat, 14 Mar 2020 19:20:22 +0000

参考书籍：Pro Java for Web Apps
注：以下内容需要HTTP基础，演示所用Java版本为Java8，所用容器为Tomcat8.5.51

Servlet是一个运行在Web服务器中的Java小程序，用于接收和响应来自Web客户端的请求，使用HTTP进行通信，是所有Web应用程序的核心类，也是唯一的既可以直接处理和响应用户请求，也可以将处理工作委托给应用中的其他部分的类。
Servlet只是一个简单的接口，包含了相关的方法。大多数情况下Servlet都继承自 $javax.servlet.GenericServlet$ 类，该类只包含一个抽象的 $service$ 方法以及一些辅助方法。$service$ 方法会处理所有请求，然后返回对应的响应。我们可以使用$javax.servlet.http.HttpServlet$ 类用于响应HTTP请求，它继承自 $GenericServlet$ 并实现其 $service$ 方法，而对于响应HTTP请求的方法只是空实现。在 $HttpServlet$ 类中，HTTP请求包括 $GET,HEAD,POST,PUT,DELETE,OPTIONS,TRACE$ 对应的响应方法名称为 $do +$ 首字母大写的请求名称。如 $GET$ 对应 $doGet()$ ，$POST$ 对应 $doPost()$ 等。除了响应方法之外，Servlet类中还包含 $init$ 方法和 $destroy$ 方法，分别在启用和关闭Servlet时调用，不过通常这些方法什么也不做。

大多数情况下我们的Servlet类都是继承 $HttpServlet$ 类。对于上述提到的所有方法，它们都接收两个参数，一个是 $javax.servlet.http.HttpServletRequest$ 类型的参数，另一个是 $javax.servlet.http.HttpServletResponse$ 类型。顾名思义，$HttpServletRequest$ 指向客户端请求，对其我们有如下常用方法：

方法	作用
$getParameter$	返回参数的单个值
$getParameterValues$	返回参数的值的数组
$getParameterMap$	返回一个包含所有参数名值对的$java.util.Map<String, String[\ \ ]>$
$getParameterNames$	返回所有可用参数的名字的枚举
$getContentLength$	返回请求正文的长度（小于 $2$ GB）
$getContentLengthLong$	返回请求正文的长度（大于 $2$ GB）
$getCharacterEncoding$	返回请求内容的字符编码
$getReader$	返回一个 $java.io.BufferedReader$ 类，可以用于读取请求的内容
$getRequestURL$	返回客户端用于创建请求的完整`URL`
$getRequestURI$	返回`URL`中的服务器路径部分
$getServletPath$	返回匹配`Servlet`映射的`URL`部分
$getHeader$	返回指定名称的第一个值
$getHeaders$	返回指定名称的所有值的枚举
$getHeaderNames$	返回请求中所有头数据的名称的枚举
$getIntHeader$	返回所有值为整型的头数据的一个值
$getDateHeader$	返回可以识别为有效时间戳的头数据的时间戳

而$HttpServletResponse$ 指向服务端响应，我们有如下常用方法：

Dijkstra算法原理及其实现

Tue, 03 Mar 2020 17:27:28 +0000

参考书籍：《算法（第4版）》

$Dijkstra$ 算法应用于带权有向图中求最短路径问题。通俗来讲就是不断选择权值最小的边加入集合直到所有顶点都在集合中，属于贪心算法。需要注意的是，$Dijkstra$ 算法只能用于解决边权非负的图类问题。
假设对于一个带权有向图 $G(V,E)$ 以邻接矩阵表示，其所有边存储在一个二维整型数组 $matrix[\ \ ][\ \ ]$ 中， $matrix[i][j]$ 表示从顶点 $i$ 到顶点 $j$ 之间的边，值为边的权值，若值为 $∞$ ，说明该边不存在。为了实现 $Dijkstra$ 算法，我们需要一个布尔值数组 $visit[\ \ ]$ ，用于判断顶点是否访问过，或者说是否在集合中；一个整型数组 $distance[\ \ ]$ 用于储存原点到每个点的最短距离。定义了基本的结构，就可以实现算法了，步骤为：

从 $V$ 中选择一个点 $s$ 作为原点，将邻接矩阵中的 $matrix[s]$ 数组复制到 $distance[s]$ （复制后 $distance[s]$ 应为 $0$ ），建立一个 $visit[\ \ ]$ 数组并清零。
从 $V$ 中选择一个顶点 $u$ 加入集合，其中点 $u$ 满足：
- 之前未曾访问过点 $u$ （即 $visit[u] = false$ ）。
- 与 $s$ 距离最短（即 $distance[u]$ 的值最小）。
以 $u$ 为中心点，对于每个与 $u$ 相邻的顶点 $k$ ，令 $distance[k] = Min(distance[k], distance[u] + matrix[u][k])$ ，这一步也称为松弛( $relaxation$ )。
重复2、3直到所有顶点加入集合。

$Dijkstra$ 算法类似于 $Prim$ 算法，实质上都是构造了一颗树。经过以上步骤之后，我们得到了一个 $distance[\ \ ]$ 数组，其中的值为从原点 $s$ 到图中其他所有点的最短距离。在使用代码实现的过程中，有些情况下我们可以使用优先队列来简化寻找最小权值的这一过程。如果我们确认了一幅图是无环图，那么我们也可以不使用 $visit[\ \ ]$ ，而是通过拓扑排序的顺序依次遍历顶点。
将上述过程转化为代码如下：

JavaScript中的数组

Sun, 01 Mar 2020 15:05:01 +0000

参考书籍：《JavaScript高级程序设计（第3版）》

作为一种可以说是最常用的类型，EMCAScript当中的数组与其他语言的数组有很大区别，例如数组元素可以是不同类型，数组长度可以动态调整等，因此我总结了一下EMCAScript中的数组类型，即 $Array$ 类型（主要集中于与其他语言不同的地方）。

1. 数组创建

EMCAScript中数组是一个特殊的类型，有自己的构造函数，我们可以通过 $new$ 运算符来调用数组的构造函数。

var array = new Array(); //建立一个空数组

当然，你也可以通过传参来调用带参构造函数。

var array1 = new Array(10); //大小为10的数组
var array2 = new Array(1, 2, 3); //包含1,2,3三个元素的数组
var array2 = new Array("A"); //包含一个"A"的数组

但是在这里要注意的是，如果你只给构造函数传一个数字，则会创建对应大小的数组,其中每一项的值都是 $undefined$ ；如果传的是多个数字，则会创建包含这些数字的数组。
除了调用构造函数之外，我们还可以使用字面量语法。如下所示：

var array1 = []; //空数组
var array2 = [1]; //包含一个1的数组
var array3 = ["A", "B", "C"]; //包含三个元素的数组

2. 数组长度

与其他语言相似，EMCAScript中的数组下标从 $0$ 开始， $length - 1$ 结束，要访问对应下标的值，可以通过方括号内添加下标读取或者写入数据，如下所示：

var array = ["A", "B", "C"];
console.log(array[0]); // "A"
array[0] = "D";
console.log(array[0]); // "D"

但是与其他语言不同的是，如果你访问的下标超过了当前数组的长度，即 $length - 1$ ，会返回 $undefined$。而你在这时写入数据的话，数组的长度会更新为你访问的下标值加一，而从原先的最大下标到新的最大下标之间的值会以 $undefined$ 填充。如下所示：

var array = ["A", "B", "C"];
console.log(array[5]); //undefined
array[5] = "F";
console.log(array[4]); //undefined
console.log(array[5]); //"F"

EMCAScript中的数组长度还有个特点，就是它不是只读的，你可以通过设置数组长度的值直接改变数组大小，这时新增的值会以 $undefined$ 填充。如下所示：

var array = ["A", "B", "C"];
array.length = 2;
console.log(array[2]); //undefined
array.length = 4;
console.log(array[2]); //undefined

3. 数组方法

EMCAScript中的数组方法非常有特点，它使得JavaScript中的数组可以代替多种结构。

Leetcode题解（2）：二分搜索

Sat, 29 Feb 2020 17:23:36 +0000

原题地址: Problem 4
参考题解

题目不用多解释，如果没有要求时间复杂度的话可以直接用双指针法遍历即可，但既然题目要求对数级的复杂度，再加上是排序数组，那么很容易就可以想到是二分法，接下来的问题就是怎么二分了。回忆下中位数的概念，中位数是一组顺序排序的数据中居于中间位置的数。也就是说，如果我们知道一组数据的中位数，我们就可以顺势以中位数为基准，将这组数据分成相同大小的两部分，其中一部分中的数总是小于（或等于）另一部分。再回到题目来，如果我们知道这两个数组的中位数，那么我们就可以将这两个数组以中位数为基准将每个数组分为两部分，如下所示：

其中左边两部分中所有的值永远小于或等于右边两部分。这时很明显中位数为

$$ median = \frac{max(nums1[i - 1], nums2[j - 1])\ +\ min(nums1[i] + nums2[j])}{2} $$

这样我们的目标就从找中位数变成了寻找一个 $i$ 和 $j$ ，满足如下条件（假设 $i$ 和 $j$ 总是存在）：

$i + j = \Large\frac{nums1.length\ +\ nums2.length}{2}\normalsize;$
$nums1[i - 1] <= nums2[j];$
$nums2[j - 1] <= nums1[i].$

根据上述条件，如果我们要进行二分搜索，第一步必须先将两个数组分别二分，保证条件1为真。

if (nums1.length > nums2.length) return findMedianSortedArrays(nums2, nums1);

int len1 = nums1.length,
    len2 = nums2.length,
    halfLen = (len1 + len2 + 1) / 2,
    i = len1 / 2,
    j = halfLen - i;
}

可以发现我们在开始判断了下$nums1[\ \ ]$和$nums2[\ \ ]$的长度，确保 $nums1.length <= nums2.length$ 。这是因为我们在下面确定 $j$ 的值时，用到的赋值式是 $j = halfLen - i$ ，如果这时不满足 $nums1.length <= nums2.length$ 则会出现 $j$ 为非正的情况，因此要进行此判断。在计算 $halfLen$ 的时候，我们将 $Len1$ 和 $Len2$ 的和加一后再求平均值，目的也是保证 $halfLen - i > 0$ ，即 $j$ 为正数。
经过上面的二分之后，我们得到了下图：

JavaScript的对象构造

Fri, 28 Feb 2020 12:48:51 +0000

参考书籍：《JavaScript高级程序设计》（第3版）

JavaScript是一门面向对象的语言，即拥有类的概念。但ECMAScript中没有类的概念，因此它的对象与其他基于类的语言不同，我们可以把ECMAScript中的对象想象成散列表，由一组组键值对构成，值可以是数据或者函数。

1.`object`构造函数模式

var person = new object();
person.name = "A";
person.sayName = function() {
    alert(this.name);
};

上例创建了一个 $person$ 对象，并为其添加了 $name$ 属性和 $sayName(\ )$ 方法，是最简单的构造对象的方法。

2.对象字面量

var person = {
    name: "XiaoMing",
    sayName: function() {
        alert(this.name);
    }
};

上例创建了相同的 $person$ 对象，不同之处在于它是使用对象字面量定义的。以花括号表示开始和结束，属性名+冒号+值的格式定义属性，用逗号隔开多个不同的属性。
在使用对象字面量时，属性名也可以使用字符串。需要注意的是，JSON只支持此种语法。

var person = {
    "name": "XiaoMing",
    "sayName": function() {
        alert(this.name);
    }
};

一般情况下，由于对象字面量语法的代码量少，开发人员大多采用此种方式构造对象。

3.工厂模式

不论是使用 $object$ 构造函数还是对象字面量，都有一个很明显的缺点，就是创建多个对象时会产生大量重复代码。因此人们采取了工厂模式的一个变种。

function createPerson(name) {
    var o = new object();
    o.name = name;
    o.sayName = function() {
        alert(this.name);
    };
    return o;
}
var person1 = createPerson("XiaoMing");
var person2 = createPerson("XiaoHong");

函数 $createPerson(\ )$ 接收参数并返回一个 $person$ 对象，每次调用均可以得到一个新的 $person$ 对象。以此，我们可以大量创建 $person$ 对象。

Leetcode周赛：177

Thu, 27 Feb 2020 11:18:21 +0000

第 177 场周赛

Problem 1360: 日期之间间隔几天

直接调用库函数即可。

import java.time.LocalDate;
import java.time.temporal.ChronoUnit;
class Solution {
    public int daysBetweenDates(String date1, String date2) {
        return (int) Math.abs(LocalDate.parse(date1).until(LocalDate.parse(date2), ChronoUnit.DAYS));
    }
}

使用 $LocalDate$ 类及其 $until(\ )$ 方法，使用 $ChronoUnit.DAYS$ 常量表明以天为单位计算。在此要注意的是Leetcode并没有默认导入 $java.time$ 类，因此要自己导入。

Problem 1361: 验证二叉树

利用二叉树的性质可以知道，二叉树根节点外每个节点有且只有一个父节点，并且有且只有一个根节点。通过这个性质，我们可以遍历数组，找到所有的节点的父节点，再验证是否符合上述性质。

class Solution {
    public boolean validateBinaryTreeNodes(int n, int[] leftChild, int[] rightChild) {
        int[] parent = new int[n]; //储存每个节点的父节点
        Arrays.fill(parent, -1);
        for (int i = 0; i < n; i++) {
            if (leftChild[i] != -1)
                if (parent[leftChild[i]] == -1) parent[leftChild[i]] = i;
                else return false; //如果该节点已有父节点，则非二叉树
            if (rightChild[i] != -1)
                if (parent[rightChild[i]] == -1) parent[rightChild[i]] = i;
                else return false;
        }
        int cnt = 0;
        for (int i : parent) if (i == -1 && ++cnt > 1) return false; //如果有多个根节点，则非二叉树
        return cnt == 1;
    }
}

Problem 1362: 最接近因数

Leetcode题解：一道”难“题

Mon, 17 Feb 2020 17:44:43 +0000

原题地址：Problem 1332

题目很直(mo)白(hu)，就是从一个字符串中删除回文子列直到字符串为空。但是我——没看示例，盯着题目描述和左上角的“简单”，陷入了长时间的思考，最终怀疑人生。毕竟如果你要找回文串的话就得遍历一遍得到子串，然后删除，再遍历，再循环……如此反复，时间复杂度很高，完全不是简单难度，毫无办法的我最终只能看向题解，然后在惊叹中一分钟提交了答案。

class Solution {
    public int removePalindromeSub(String s) {
        if (s.length() == 0) return 0;
        else if (s.equals(new StringBuilder(s).reverse().toString())) return 1;
        else return 2;
    }
}

总之这道题很沙雕，沙雕之处就在于它的子序列可以不连续。所以，如果不是空串或者回文串的话，先删掉所有的 $a$ 再删掉所有的 $b$ 就行了。由于让我卡了很久，专门写了一篇博客，特此留念。

Leetcode题解（1）：动态规划

Wed, 12 Feb 2020 20:42:30 +0000

原题地址：Problem 62

参考题解

第一眼看到这道题就联想到了离散数学里的排列的相关知识，从而可以很容易的得出排列数为 $C(m+n-2,m-1)$ 或者 $C(m+n-2,n-1)$，可以直接利用该公式进行计算。但问题是阶乘的增长量级过大，很快就产生了溢出的问题，这时可以通过使用 $BigInteger$ 类型对象解决。
虽然问题解决了，但显然这种偏暴力方式的解法不是我们的目的，因此我们还要寻找另一种解法。通过观察题目，我们可以很明显的发现：由于只能右移或者下移，因此到达每一块方格的路径数（不包括第一行和第一列） = 到达其左边方格的路径数 + 到达其上边方格的路径数。以此规律，我们可以运用动态规划来解决该问题。

首先先设

int[][] dp = new int[m][n];

dp数组为二维数组，储存到达每个方格的路径数。由于达到第一列和第一行中所有方格的路径数有且仅有一条，因此可以

for (int i = 0; i < m; i++) dp[i][0] = 1;
for (int i = 1; i < n; i++) dp[0][i] = 1;

之后仅需双循环进行赋值即可：

for (int i = 1; i < m; i++)
    for (int j = 1; j < n; j++) 
        dp[i][j] = dp[i - 1][j] + dp[i][j - 1];

在此，无论是按行还是按列，结果都是一样的。最后 $dp[m - 1][n - 1]$ 即为答案。将上述代码合并起来即为：

JavaScript的对象继承

Fri, 06 Dec 2019 22:58:43 +0000

参考书籍：《JavaScript高级程序设计》（第3版）

继承是OO语言（面对对象语言）中的概念。许多OO语言都支持两种继承方式：接口继承（继承方法签名）和实现继承（继承实际方法）。但由于JavaScript中没有签名，因此在ECMAScript中只能实现方法继承。

1. 原型链

原型链（ $prototype\ \ chaining$ ）是实现继承的主要方法。基本思想是利用原型让一个引用类型继承另一个引用类型的属性和方法。

function SuperType() {
    this.property = true;
}
SuperType.property.getSuperValue = function() {
    return this.property;
};
function SubType() {
    this.subproperty = false;
}
//继承SuperType
SubType.prototype = new SuperType();
SubType.prototype.getSubValue = function() {
    return this.subproperty;
}

上述代码中定义了两种类型—— $SuperType$ 和 $SubType$ ，其中 $SubType$ 继承了 $SuperType$ 。实现的本质是重写 $SubType$ 的原型对象，即将一个 $SuperType$ 对象赋给 $SubType.property$ ，从而使得 $SuperType$ 中所有的属性和方法均存在于 $SubType$ 中。在实例中，我们也给 $SubType$ 添加了一个新方法。此外，还要注意，以此种方式实现的继承中， $SubType.constructor$ 指向的是 $SuperType$ 。
原型链能够实现继承，但也存在问题。由于是直接赋值给原型，因此其中的属性会被所有实例共享。如以下代码：

function SuperType() {
    this.colors = ["red"];
}
function SubType() {}
SubType.prototype = new SuperType();

var instance1 = new SubType();
instance1.colors.push("blue");
alert(instance1.colors); //"red,blue"

var instance2 = new SubType();
alert(instance2.colors); //"red,blue"

还有，不能通过子类调用超类的有参构造函数等。
由于种种原因，实践中很少单独使用原型链。

get in touch

Mon, 01 Jan 0001 00:00:00 +0000

z217's blog

C++协程（5）：理解编译器转换

介绍

设置场景

定义 task 类型

C++协程（4）：理解对称转移

首先是一些关于任务协程怎么工作的背景

C++协程（3）：理解promise

协程概念

Promise对象

C++协程（2）：理解co_await

协程标准带来了什么？

编译器 <-> 库交互

C++协程（1）：协程理论

协程是函数，函数是协程

“普通”函数

调用帧

调用

返回

分布式数据系统：共识算法

1. 原子提交与两阶段提交

1.1 两阶段提交

2. 分布式事务实践

2.1 Exactly-once消息处理

2.2 XA事务

分布式数据系统：主从节点

1. 主从模式

1.1 同步复制

1.2 异步复制

1.2.1 读写一致性

1.2.2 单调读

1.2.3 前缀一致读

1.3 节点失效

1.3.1 从节点失效

1.3.2 主节点失效

1.4 日志

1.4.1 语句复制

C++ Templates（6）：模版实践与泛型库

1. 包含模式

1.1 链接错误

1.2 头文件中的模版

C++ Templates（5）：编译时编程

1. 模版元编程

C++ Templates（4）：移动与引用

1. 移动语义

1.1 完美转发

C++ Templates（3）：基本技术

1. typename

2. 零初始化

3. 原始数组和字符串常量模版

C++ Templates（2）：非类模版参数

1. 非类模版参数

1.1 非类模版参数类

1.2 非类模版参数函数

C++ Templates（1）：函数模版和类模版

1. 函数模版

EffectiveModernCpp（7）：通用技巧

1. 值传递

EffectiveModernCpp（6）：并发

1. std::async

2. 启动策略

EffectiveModernCpp（5）：Lambda

1. 捕获模式

EffectiveModernCpp（4）：引用

1. move和forward

EffectiveModernCpp（3）：智能指针

1. unique_ptr

EffectiveModernCpp（2）：使用现代C++语法

1. 初始化

EffectiveModernCpp（1）：类型推导

1. 类型推导

1.1 情况一

Unix网络编程补充：eventfd和timerfd

1. eventfd

Unix网络编程补充：epoll

1. epoll操作

Unix网络编程（20）：共享内存

1. 共享内存操作

Unix网络编程（19）：信号量

1. 有名信号量操作

2.1 `Exactly-once`消息处理

2.2 `XA`事务

1. `typename`

1. `std::async`

1. `move`和`forward`

1. `unique_ptr`

1. `eventfd`

1. `epoll`操作

1. `mq_open`、`mq_close`和`mq_unlink`函数

1. `getsockopt`和`setsockop`函数

2.1 `SO_DEBUG`

1. `TCP`预先派生子进程服务器程序，`accept`无上锁保护

1.1 `pthread_create`函数

1. 套接字的信号驱动式`I/O`

1.1 对于`UDP`套接字的`SIGIO`信号

1.2 对于`TCP`套接字的`SIGIO`信号

2. 使用`SIGIO`的`UDP`回射服务器程序

1. `TCP`带外数据

1. `ioctl`函数

1. `syslogd`守护进程

2. `syslog`函数

1. 基本`UDP`套接字编程

1.1 `recvfrom`和`sendto`函数

1.2 `connect`函数

1. `I/O`模型

1.1 阻塞式`I/O`

1.2 非阻塞式`I/O`

1.3 `I/O`复用

1.4 信号驱动式`I/O`

1.5 异步`I/O`

2. `select`函数

1. 基本`TCP`套接字编程

1.1 `socket`函数

1.2 `connect`函数