sinat_14913533的博客

要写出能够运行的代码是比较容易的，但是要写出优雅的、逻辑简单直接、换个人接手不容易出错的代码是比较难的。一方面其实是靠程序员单兵的代码水平，但是现实情况就是一个团队的同学对代码的认识和追求就是参差不齐，而且在国内，我遇到的团队中，大概率大部分追求的是可运行的代码，不太会真的去care的代码的质量的。亲身经历的告诉我，大阿里的技术专家几乎都是非常功利主义的编程，拿结果、完成所谓的kpi才是王道。但另一方面，其实是可以通过规约的方式，拉齐大家的认知，减少这种错误。、中文翻译。

cpu的衡量指标使用率util：代表的是单位时间内CPU繁忙情况的统计。操作系统对cpu的管理就是利用周期的tick时钟中断，将cpu的使用划分时间片。每个时间片内去执行不同进程/线程里的代码。所以cpu的使用率统计其实也是以tick为单位的：统计周期内，有多少个tick是在执行进程/线程里的指令的。top、pidstat等工具查看到的cpu使用率是指统计周期内cpu的占用情况load：平均负载是指单位时间内，系统处于可运行状态和不可中断状态的平均进程数，也就是平均活跃进程数，

​​​​​​​Future其实是对将来某个时刻会发生的结果进行建模，封装了一种异步计算，返回这个异步计算结果的引用，通过这个引用可以获得运算的状态，以及当运算结束后可以通过这个引用获取异步运算的结果。这比直接使用Thread会好用很多。通过Future之所以能够获得子线程异步计算的结果，其本质是因为父子线程是共享使用了进程分配的资源。

redis通过在slave上执行replicaof 主节点ip 主节点port来建立主从关系，当执行了这个命令时：建立主从关系会执行一次全量数据同步从节点发送psync请求给主节点主节点收到请求后，会生成一个全量的rdb文件，然后将rdb文件传输给从节点从节点收到rdb文件后，会先清空自己本地的数据，然后加载rdb文件。ps：这个过程是消耗比较大的。后续增量的修改，都会将修改命令异步同步给从节点。主从关系建立后，主节点所有对数据修改的命令都会同步给从节点，以此保证主从数据的一致。

中将锁的本质分成了两部分，来分析理解锁的本质，并结合了java中的锁从这两部分来分析理解锁标志的存储加锁时，遇到锁被占用该怎么办。分布式锁的本质也是个锁，其实同样是从这两方面来分析。锁标志的存储。对于线程锁，锁标志的存储就需要放到所有线程都可以访问的地方，而线程都是共享进程的资源的，所以毫无疑问，锁标志都是放到进程中的，这样进程下的线程都是可以访问到。

bio、nio、aio、io多路复用、reactor模式io，在将IO的时候，是不是都遇到过这些概念，也有种傻傻分不清？甚至别人在大谈特谈的时候，一会nio，一会io多路复用，一会又搞到reactor模式上去了？这些概念到底是什么？什么关系？这些都是我曾经的疑问。这里说明一下这些概念，帮助理解redis的单线程+io多路复用实现高性能，因为很多其他这种需要IO的也使用了多路复用，但并不是单线程，比如netty，也实现了高性能的io，啥区别呢？下面就结合掌握的只是和理解，来尝试理清楚这些概念。

linux环境下，redis客户端和服务端的是通过linux提供的socket接口来实现网络通信的。这里简单介绍小socket的缓冲区，操作系统内核会为每个socket分配一个读缓冲区和写缓冲区，即socket的缓冲区是内核空间中内存区域：对于接收网络数据，内核是将接收的数据先存放在缓冲区的，应用线程是去缓冲区读取数据。如果应用线程读取数据的时候，缓冲区是空的，那就会阻塞应用线程(当然也有非阻塞的方式)

这个和查找第一个相等元素一模一样，无非就是第一个是向前找；而最后一个是向后找// 查找最后一个相等的int l = 0;if (mid == arr.length - 1) {// 防止mid+1越界return mid;// 最后一个小于等于int l = 0;// 中间比target大，那么第一个比target小的一定在左边} else {return mid;} else {

redis的全局hash表的桶位存储是个Entry结构，Entry里的value指针指向的是一个RedisObject结构，这个RedisObject才是真正承载value数据的结构。前面简单介绍了RedisObject包含两部分元数据和指针，其8字节的元数据进一步分成了4个字段8字节的元数据：type：value的类型，包括了redis内置的string、list、map、set、sortedset、hyperloglog。

在操作系统里面，也会遇到什么信号量、互斥量，然后说利用互斥量、信号量可以实现锁的功能，而操作系统提供的原语有又mutex锁在学习数据库的时候，什么表锁、行锁、读锁、写锁、排它锁、意向锁、meta锁等等，各种各样的锁的概念蜂拥而至在学习java的时候，我们会学习到synchronize关键字、jdk里的Lock接口，然后有各种各样的Lock的实现；然后在聊synchronize的时候又会又各种锁的概念出来：自旋锁、偏向锁、轻量级锁、重量级锁。

B+树和LSM-Tree简介

在web项目中，有不少场景需要统一处理一些和实际业务基本不相关的逻辑，比如rest接口的监控、出入参日志、操作记录、统一异常处理(避免将错误堆栈等信息直接打到web端)。如果你觉得日志打印rest接口出入参非常简单，直接getParameter()就好了，那么多思考3s继续看吧。

我们常见的缓存是基于内存的缓存，但是单机的内存是有限的，不能让缓存数据撑爆内存，所有需要缓存淘汰机制。中大概说明了LRU的缓存淘汰机制，以及基于LRU的著名实现guava cache。除了LRU淘汰策略外，其是常见的还有FIFO以及LFU，只是说目前用的最多的是LRU。

kafka的消息模型

垃圾回收过程其实都包含两步：标记+回收。综合来看，复制算法适合在垃圾回收执行时存活对象比较少的场景；整理算法适合在垃圾回收时存活对象较多但是不能有内存碎片的场景；而清理算法因为会产品内存碎片，实际的场景其实并不多，CMS使用该算法，但也诟病比较多。对于一个java进程中的对象，经过统计发现，大部分对象生命期都是比较短的，活不过一次垃圾回收，而少部分生命期比较长，多次gc后依然存在，甚至和java进程生命期相同。针对这种情况，就对java的内存进行了分区，不同分区使用不同的回收算法，来达到最大的收集效果。

至于实体充血不充血，我本来就是微服务了，业务粒度本来就很小了，要怎么写是我的自由，改造也是我自己的成本，我并不需要按照你那一套来。原谅我使用“限界上下文”这样的名词来解释一下：你只要把我的服务边界划分清楚了，你管我后面是怎么实现呢，设计模式和架构模式，我的工具箱多的很，并不缺CQRS、事件溯源这样的名词。这三个词，很伟大，它们有一个共同点，都是很容易说服非技术但能决策的人员，然后向下铺开，非常具有营销型，是职业经理人和CTO的最爱。你搜一下DDD的文章，不论什么文章，都有一个特点，那就是不能好好的说人话。

这个话题来自一个面试，当问到Socket编程中的accept()是否有惊群问题，引深又文档epoll多路复用中epoll_wait()是否有惊群问题。因为没有准备背过八股文，突然问到这个问题，还是稍微有点措手不及，当然就没有背过的那么快速干脆了，而对方在强调结果，也没给我思考分析的时间，我还在仔细回想这个里哪里存在惊群问题的时候，对方已经打断我说好了。所以这里就记录分析一下，到底什么是惊群效应，以及在并发编程中的应对方式。

操作系统早期的IO都是阻塞式的，所以为了一个应用能够支持并发的IO操作，所以基本的做法就是每来一个IO请求，就创建一个线程来专门处理。当IO并发不大的情况，这中方式工作的很好但随着IO并发越来越大，到了每秒需要支持1000的并发量的时候，那么就需要创建1000个线程来支持。随着线程越来越多，极大的超出了cpu的核心数，那么随之而来的就cpu调度成本增加、大量的上下文切换、以及线程的内存消耗等，这些都将成为并发量继续增加的瓶颈。所以并发量很大的情况下，就不再适合用这种模型来处理。

这个其实是遇到的一道面试题，其题目描述也很简单，BIO和NIO消耗的cpu和内存哪个比较大。因为确实从来没遇到过去从这个角度去比较NIO和BIO的，所以我尝试变结实原来，边分析，但是整个过程对方三次认为我跑题了，强调回到他问题的本身，先给出答案，所以整个过程其实并没有真的深入去分析。但我觉得这个问题有点意思，就记录一下，从我掌握的知识来分析一下。..............................

top统计的是当前统计窗口里的情况。一般情况下，只要不是宿主机上的所有容器负载都很大，超卖是没有影响的，即只要没有把物理机cpu打满，超卖就超卖，反正也用不完，但是只要某一时刻兄弟们要求的12个cpu都要用的时候，那就完了，物理机cpu使用率飙高，这个时候进程上下文切换更加频繁，雪上加霜，系统会更慢的。但还有一点人性没有泯灭，当时这么写的时候，其实有点膈应，但是一个闪念的想法让我就这么写了：任务里的操作其实会很快，因为有两层缓存，即走到了db，也一定走上索引，应该不会慢的，就这样吧，应该问题不大。