Idea 默认快捷键
记录一下Idea默认的快捷键，更方便提高开发效率。
tanzhuo
线程池核心线程数-计算方式
线程池的工况一般分为三种场景：
1、计算密集型
需要大量的计算，对 CPU 高占用率，CPU Loading 90-100%，除开 CPU需要读/写I/O(硬盘/内存)，但这些 I/O 只需要很短的时间就可以完成，更多的是 CPU 需要进行很多数据运算，数学运算，CPU Loading 很高的场景。
例如数据分析，数据流处理，此类程序运行的过程中，CPU占用率一般都很高。
假如在单核CPU情况下，线程池有6个线程，但是由于是单核CPU，所以同一时间只能运行一个线程，考虑到线程之间还有上下文切换的时间消耗，还不如单个线程执行高效。所以，单核 CPU 处理计算密集型程序，就不要使用多线程了。
假如是6个核心的CPU，设置6个线程数，理论上运行速度可以提升6倍（但实际上达不到，多线程之间有并发以及需要优化的地方）。每个线程都有 CPU 来运行，
InnoDB 之 BufferPool 详解
BufferPool官方文档：
MySQL :: MySQL 8.0 Reference Manual :: 15.5.1 Buffer Pool
在InnoDB存储引擎中，为了提高MySQL服务性能，减少磁盘IO次数，故此所有的DML操作均是在内存中的 BufferPool 中完成。最后通过服务的异步刷盘策略把修改数据落盘到磁盘中。
为什么需要设计 BufferPool ？这里我想一般有计算机基础知识的人都知道，内存和硬盘的效率是天差地别的，对于CPU来说硬盘的传输以及响应时间性能太低下，故此 MySQL 设计出了 BufferPool 来映射磁盘中的真实数据，并在内存中进行数据的管理与操作，这样执行DML语句的效率不就起飞了吗？至于是如何保障内存中的 BufferPool 数据在宕机，掉电的场景不会出现丢失（物理打击除外😃，大力出奇迹，硬盘都给你扬了），之前我的文章中也有所讲解：
MySQL 执行链路当客户端SQL语句提交给 MySQL 服务器时首先需要建立连接，连接器会与客户端进行连接，并校验用户身份信息，权限信息，如果权限通过，则通过SQL分析器对SQL语句进行语义分
MySQL 执行链路
当客户端SQL语句提交给 MySQL 服务器时首先需要建立连接，连接器会与客户端进行连接，并校验用户身份信息，权限信息，如果权限通过，则通过SQL分析器对SQL语句进行语义分析（检查SQL语句是否合法，能否解析通过），分析完成后将会对SQL的执行过程进行优化，例如剔除不必要的查询条件 1=1 ，以及选择最优的索引与Where条件的字段排序。
然后交给执行器执行此SQL语句，执行器将会根据数据库所使用的存储引擎执行SQL。MySQL在设计时是分为了两层，即Server层和存储引擎层。这样做的好处就是解藕，可以根据不同的数据库去选择合适的存储引擎。
常用的InnoDB存储引擎是以页（16KB）为单位来管理存储空间的，任何的增删改差操作最终都会操作完整的一个页，会将整个页加载到 BufferPool 中并且所有的数据操作都是在 BufferPool 中完成，BufferPool 通常设置为服务器60%-70%左右的内存占用，这样数据的操作直接在内存中执行，从而提高数据操作的效率（如果每一条DML语句都要进行 IO 操作那么数据库的磁盘很容易变成瓶颈，改一条数据需要先从磁盘中读取，然后刷盘
JVM 线程池扩容机制
在 HotSpot VM 的线程模型中，Java 线程被一对一映射为内核线程（JDK19后已经引入携程 UT）。及一个 LWP 线程对应操作系统内核中的 KLT，Java 在使用线程执行程序时，需要调用操作系统内核的 API，创建一个内核线程，操作系统要为线程分配一系列的资源，当该 Java 线程被终止时，这个内核线程也会被回收。
因此 Java 线程的创建与销毁的成本很高，会增加系统的性能开销。并且线程也不能创建太多，因为CPU切换线程去执行指令时需要处理对应上下文信息。大量的线程将会导致CPU的性能存在一定损耗。毕竟我们CPU的核心数是有限的，如果我们无限制地创建线程还可能导致 OOM。
故此我们主要来看 ThreadPoolExecutor 类的参数：
int corePoolSize [核心线程数]
int maximumPoolSize [最大线程数]
long keepAliveTime [存活时间]
TimeUnit unit [时间单位]
BlockingQueue workQueue
HTTP 协议发展史
HTTP 是浏览器与服务端之间最主要的通信协议，HTTP 是应用层协议（7层），应用层产生的数据会通过传输层协议作为载体来传输到互联网上的其他主机中，而其中的载体就是 TCP 协议（3.0使用UDP），基于 TCP 协议进行连接，然后传输对应内容信息。
20 世纪 60 年代，美国国防部高等研究计划署（ARPA）建立了 ARPA 网，这被认为是互联网的起源。70 年代，研究人员基于对 ARPA 网的实践和思考，发明出了著名的 TCP/IP 协议。该协议具有良好的分层结构和稳定的性能，并在 80 年代中期进入了 UNIX 系统内核，促使更多的计算机接入了网络。
1989 年，蒂姆伯纳斯-李博士发表了一篇论文，提出了在互联网上构建超链接文档系统的构想。在篇文章中他确立了三项关键技术：URI、HTML、HTTP。
基于这三项技术，
布隆过滤器详解
布隆过滤器（Bloom
Filter）是1970年由布隆提出的，它实际上是由一个很长的二进制向量和一系列随意映射函数组成。布隆过滤器使用场景一般是防止redis缓存穿透，使用布隆过滤器可以更好的节省空间，并且快速定位元素是否存在。
布隆过滤器通过 hash key 来定位
位图（Bitmap，其实就是bit数组）中对应的下标，并且在这个数组中每一个位置只有0和1两种状态，每个位置只占用1个字节，其中0表示没有元素存在，1表示有元素存在。
注意：两个不同的key哈希出来所对应的下标位可能存在部分重复，这样可以减少内存的占用，但也有概率会出现哈希碰撞，原本不存在的key哈希之后位图中都为1的情况。
所以通过上面的现象，我们从布隆过滤器的角度可以得出布隆过滤器主要有2大特点：
1、如果布隆过滤器判断一个元素存在，那么这个元素可能存在。
2、如果布隆过滤器判断一个元素不存在，那么这个元素一定不存在。
因为布隆过滤器中总是会存在误判率，因为哈希碰撞是不可能百分百避免的。布隆过滤器对这种误判率称之为假阳性概率，即：False Positive
Probability，简称为fpp。
隐藏性能杀手之 '伪共享'
随着CPU工艺的发展，目前的高端CPU已经存在几十核心百多个线程，并为CPU设计出了一二三级缓存。CPU的核心有了这些缓存就可以加快数据的处理，从而减少访问内存的频率，这样CPU的计算性能可以进一步得到提高。
CPU的缓存结构以及内存硬盘：
众所周知CPU去访问一次内存所需要的开销是非常之大的，想要获取一次磁盘上的数据更是需要等待较长的时间，虽然目前已经有很多解决方案如 mmap
技术来缓解这样的情况，但总体来说CPU的计算性能是整个计算机结构中的天花板，其他硬件从数据传输速度层面对比起来就显得拖后腿，那么我们来看一下具体CPU访问每个硬件的延迟：
存储器存储介质介质成本（美元）随机访问延迟L1 cacheSRAM71nsL2 cacheSRAM74nsMemoryDRAM0.015100nsDisk
SSD(NAND)0.0004150usDiskHHD0.0000410ms
可以得出外部存储设备容量越大成本越小，存储数据更多，但访问速度更慢，访问速度越快的设备造价更高，并且可以看到， CPU 访问 L1 Cache 速度比访问内存快
100 倍，这就是为什么 CPU 里会有
安全容器运行时 Kata
传统的轻量级容器是基于Linux namespace和cgroup进行容器隔离，在带来轻量，简洁，高效的同时，也带来了安全的隐患。
事实上容器虽然提供一个与系统中的其它进程资源相隔离的执行环境，但是与宿主机系统是共享内核的，如果其中某一个容器被攻击，从而导致把宿主机的内核给攻掉了，那么其他的容器势必都会崩溃。后果不堪设想。
那么有没有什么容器技术及安全又比较高效率的呢？于是便出现了 Kata 容器技术。
Kata Containers - Open Source Container Runtime SoftwareKata Containers is an
open source container runtime, building lightweight virtual machines that
seamlessly plug into the containers ecosystem.An OpenInfra Project
[https://katacontainers.io/]Kata
实际上是通过创建轻量级虚拟机实现容器之间的资源隔离，
Istio 之流量镜像
通过在k8s集群中部署Istio作为Service Mesh架构，利用它本身的Envoy代理转发流量的特性，轻松的支持了流量镜像的功能，只需要在配置文件中简单加上几个配置即可完成流量镜像，此功能非常强大，如用得当可以更好的服务生产环境的业务需求。流量镜像也被称作影子流量，把客户端打入的请求进行复制并转发到其他容器进行处理，但镜像的流量不会响应数据给客户端，如此一来流量镜像的价值就变得非常清晰，我们可以用流量镜像做数据记录，风控分析，线上异常操作跟踪，并且对于原来的业务代码是完全透明的，毕竟在流量进入容器前已经进行了流量的镜像，并通过部署其他容器服务进行处理。极大的增强了业务的横向扩展能力。
镜像此任务演示了 Istio 的流量镜像/影子功能。Istio阅读大约需要 3 分钟 页面测试
针对流量镜像的典型的使用场景：
1、测试环境：测试版本的容器服务可以使用生产实例的真实流量，不会影响正常生产的关键路径。例如预发布环境就可以更好的进行实时测试校验，减少发布后出现的各种异常情况，给开发团队更好的上线信心 😂，上线几乎可以做到清晰明了，不用熬夜加班发版。
2、数据采集：同步收集请求