JDK1.8 中对HashMap底层进行了改造，例如扩容重散列算法优化、加入链表过长转红黑树结构等。
鉴于日常搬砖靠HashMap打天下，面试题基本跑不了，全面认知散列表必不可少。

结构

散列表的实现方法有两种：

• 开放地址法(Hashing with linear probing)
  
• 链接地址法(Hashing with separate chaining)
  

project

learn on project springboot-learning-example

1

git clone https://github.com/JeffLi1993/springboot-learning-example.git

copy module springboot-mybatis-redis to springboot-redis
modify pom.xml, remove mybatis/mysql, add lombok

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

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>springboot</groupId>
    <artifactId>springboot-redis</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name>springboot-redis :: 使用 Redis 作为缓存</name>

    ...

    <dependencies>

        ...

        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <version>1.16.14</version>
        </dependency>
    </dependencies>
</project>

前言

　　今天开始，打算写一系列有关日语的随笔。不定期更新。这些内容一般不会在任何教科书里提到，考试当然也不会考到。所以，主要是我个人的研究爱好了。这系列的文章，主要是从日语的发展角度来对现在的一些常用词作出解释，从某种角度来说，我认为这也可以帮助学习日语的人来加深理解，起到一定的提高作用。
　　大多数内容都是基础的，有一点日语基础的人应该都可以阅读。

日语随笔　前言 (2006-09-04 12:12:29)

（一）从“海”的音读说起

日语里分音读和训读。汉字作音读的时候，其发音和中文类似，这一点对于学习日语的中国人来说，是比较方便的。
　　但是，有一些汉字，音读的发音和中文的发音还是有不少区别的，我们有时候会很气恼，为什么日本人偏要把我们的发音改掉呢，好好地发成一样不是很好吗？教科书的解释，一般是说，日语的音读是采用了中国的古音，所以和现代的汉语有差距。
　　很多情况下的确如此，但也并不全是这样。比如“海”字。中文发“Ｈａｉ”（はい），日语发“Ｋａｉ”（かい），但是，并不是说这个字在中国古代发作Ｋａｉ，后来变成Ｈａｉ。事实上，“海”这个字，中国历史上从来没有发作Ｋａｉ过。即使不发Ｈａｉ，也是Ｈｅ，或者Ｈｅｉ，总而言之，和“Ｋ”是没有关系的。

　　那么日本人引进这个字的时候，为什么不用はい作为读音，而用かい呢？答案很简单，在日本古代，は这个假名不发音为Ｈａ，而是发音为Ｐａ。
　　在室町以前，はひふへほ的发音，是Ｐａ，Ｐｉ，Ｐｕ，Ｐｅ，Ｐｏ。而日语里面，没有Ｈａ这个音。于是，对于“海”这个字的注音，只能在比较接近的Ｋａｉ，Ｇａｉ，Ｐａｉ中挑选，显然，Ｋａｉ的发音更为接近。
　　同样的原因，所有中文里以Ｈ为声母的汉字，到了日本后，发音全变成了か行，当然有一些因为浊化而成为が行。除了“海”，其他的例子还有“好”、“浩”、“号”等字，中文发音为Ｈａｏ，日语音读为こう（Ｋｏｕ）或者ごう（Ｇｏｕ）；贺，中文发音为Ｈｅ，日语发音则为か（Ｋａ）；黑，中文发音为Ｈｅｉ，日语发音则为こく（Ｋｏｋｕ）等等，大家可以自己再找许多例子出来，这里不多写了。
　　但是，有人可能要问，如果は行全变成了か行，那么日语中不是就不存在Ｈａｉ的音读了吗？当然不是。这一点，我们下一期再说吧。

追根溯源，日语漫谈（一）从“海”的音读说起 (2006-09-04 12:14:13)

Apache Kafka具有称为“请求炼狱”的数据结构。炼狱将保留所有尚未满足其成功条件但还没有导致错误的请求。问题是“我们如何有效地跟踪集群中其他活动异步满足的成千上万个请求？”

Kafka实现了几种请求类型，这些请求类型无法立即通过响应进行响应。例子：

• 在所有同步副本都确认该写入之前，不能将acks = all的生产请求视为已完成，如此我们可以保证，如果领导者失败，该请求也不会丢失。
• 直到至少有一个新字节的数据供消费者使用时，才会回答min.bytes = 1的提取请求。这允许进行“长时间轮询”，以便用户不必忙于等待检查新数据的到来。

当（a）他们要求的条件完成或（b）发生某些超时时，这些请求被视为完成。

在任何时候，运行中的这些异步操作的数量与连接的数量成比例，对于卡夫卡而言，连接的数量通常为数万。

请求炼狱是为如此大规模的请求处理而设计的，但是旧的实现有许多缺陷。

在此博客中，我想解释旧实现的问题以及新实现如何解决它。我还将介绍基准测试结果。

The begining

https://kafka-tutorials.confluent.io/kafka-console-consumer-producer-basics/kafka.html
i saw confluent.io‘s code block is great.
it have feature like clipboard/ collapsible, even font looke good.
so i want add clipboard function to my blog at first.

at first i search by markdown code block copy, but no article helps.
then i search by hexo next theme code block, finally find the article i want.

Hexo NexT 代码块复制功能

原初

单线程的Redis为什么如此快?

• 纯内存操作
• 单线程操作，避免了频繁的上下文切换,
• 采用了非阻塞I/O多路复用机制

看到Redis高性能的原因里，有IO多路复用一项，感到非常好奇具体是怎么实现的呢。

网上浏览了一圈，代码探索了一遍，发现复用发生在系统内核。
软件层面通过系统函数库epoll 、 iocp，把IO组织起来，我大致是这样理解的。

在之前写 探索redis 键散列过程源码 文章时，看到redis有用到事件机制。
这回，在查Redis多路复用时，也看到了这个机制，决定将事件粗略探索一下，范围就定在“文件事件”上。

事件

• 事件处理器用multiplexing监听多个套接字，根据行为的不同关联不同事件处理器
• 被监听的套接字准备好执行 accept, read, write, close等操作时，会产生相对应的事件，触发事先关联的事件处理器(ps. 回调函数)处理

声明：单变量微积分的内容到这里就结束了，衷心希望可以帮到大家，再次谢谢大家的支持。

前面的文章中我们已经看到如何使用积分来解决几何和基本物理中产生的问题。

本节，我们简短介绍一下流体静力学，它主要关注液体的行为，尤其是，我们计算一个开口容器内部的水向外的作用力。我们可以考虑任何容器，可以是一个很小的鱼缸，也可是巨型大坝水库。之所以将它，是因为它更好的解释了前几篇文章的主题(将要计算的量划分为许多方便的小块，然后添加计算也就是积分得到要计算的量)。

有一个底面是矩形的盒子，里面的水深为$h$(图1)，那么底部受到向下的力等于盒内水的重量。如果$A$是底部的面积，那么由公式给出

其中$w$是水的质量密度，近似为$62.5\ lb/ft^3$或者$\frac{1}{32}ton/ft^3$。很明显(1)中的度量单位需要兼容。我们用$feet$度量$h$，$square\ feet$度量$A$，$pounds$或者$tons\ per-\ cubic\ foot$度量$w$。那么力$F$就是$pounds\ or\ tons$。

图1

让我们考虑$x$轴上方的平滑曲线，如图1左边所示。当这条曲线绕$x$轴旋转时，它会生成一个曲面。现在我们开始解决曲面的表面积问题。

图1

首先提一个常识，在移动的对象上施加一个发力，如举起一块很沉的石头，我们感觉需要很大的力气或做功。在我们定义物理上功的概念之前，我们深信移动相同的距离，举起20磅的石头所做的功是l0磅的两倍，并且俱到3英尺所做的功是1 英尺的三倍。这些想法给出了我们基本的定义：如果恒力$F$作用的距离为$d$，那么这个过程中完成的功为力和它作用距离的乘积

或者

弧是介于曲线上两个特定点$A$和点$B$之间的一部分，如图1 左边所示。物理上，弧长是一个非常简单的概念。数学上，它是稍微有点复杂。从物理观点看，我们只是折弯了一根绳子来拟合从$A$到$B$的曲线，标记下对应的点$A$和$B$，将绳子伸直然后用尺子量出长度。

这一过程可以用如下的逼近过程(适合于数学处理)来解决。弧$AB$用点$P_0=A,P_1,P-2,\ldots,P_n=B$分成$n$部分；将针放在这些点上；让该线段沿着这些一个个短针得到的路径延伸。我们在图1右边用$n=3$的情况说明了这个想法。$A,B$之间的长度明显短于弧长，因为两个点之间直线最短。然而，如果我们采取更大的$n$值，同时要求针之间放置的足够近，那么线的长度应该接近弧的长度。我们现在用数学语言表达它并推导出用积分计算弧长的实用方法。

图1