u010900754的专栏

跳表一种针对链表的快速查询数据结构。理论分析，给定一个静态的链表，如果每两个节点构建一个上层索引链表，查询时间变成On/2。如果再往上构建，变为On/4。一直往上构建到k层，假设k层有x个节点，那么只需要遍历Ox。也就是只有最上层的链表需要遍历，之下的链表最多3个节点是常数级别。又因为最上层的链表数最多为2，所以可以有这个结论：每一层至多遍历3个节点。那么总共几层呢？显然是logn，所以这个跳表的查询时间复杂度是logn。在实际运用的时候，链表会动态添加或者删减，我们需要同步调整索引结构，此时无法完全

ThreadLocal作用线程级别变量隔离，减少多线程访问变量时加锁带来的性能损耗。缺点使用不当可能导致oom。原理弱引用是精髓。get方法 public T get() { Thread t = Thread.currentThread(); ThreadLocalMap map = getMap(t); if (map != null) { ThreadLocalMap.Entry e = m

Java引用类型分为4种。1.强引用正常来说，用一个引用指向new出的对象，都是强引用类型。比如String s = new String(""); 这里的s就是一个强引用。如果对象被强引用指向，那么这个对象无论如何都不会被gc回收，即便发生oom。2.软引用String s = new String("abc");SoftReference<String> r = new SoftReference<>(s);软引用的特点是，如果对象仅仅被软引用指向，gc时

每一个分区一个文件夹，一个分区对应多个文件。当满足一定条件后，会生成新的文件。每一个文件叫做一个日志段，每一个日志段会关联两个索引文件，一个是偏移量索引另一个是时间戳索引。日志段以本日志内的第一条消息的偏移量命名。段内的日志偏移量是相对偏移量。一个分区只有最新的日志段是可写的，其余的都是只读。索引文件：并非每一条消息都对应一个索引项，而是积累到一定数量后，插入一条索引项。1.偏移量：按照偏移量排序，存放的是偏移量到物理位置，查找时二分法查找。2.时间偏移量：按照时间戳排序，查找时二.

任务数据想要持久化或者进行网络传输，都需要进行序列化。序列化方式可以分两种：字节流或者字符流。字节流：机器友好，传输效率更高，占用更小的空间，如果追求性能，优先考虑。常见的比如mysql、kafka等，都使用的字节流协议；字符流：人类友好，可读性更好，拿到消息体后便可解析消息内容。但是效率较低，毕竟一个字符至少占用一个字节。常见的比如http协议就是字符流协议；下面看下kafka的消息格式或者协议。kafka消息格式经过了几个版本。消息以消息集的形式存在。消息集内的每一条消息由off

/** * Reactor模式简述 * * Reactor负责轮询selector，将就绪事件分发给handler处理。 * handler大致有两种： * 1.acceptor：负责建连，建连后注册io handler； * 2.io handler：负责处理io读写事件； * * 所以Reactor模式是一种事件响应式模式。提前注册handler。selectionKey的作用是将handler与channel关联（注册事件时不能指定handler） * 当select返回就绪事.

用户态 vs 内核态：操作系统也是程序，有对应的程序代码，而且也要占用内存。计算机的部分内存以及部分函数就是专门分给操作系统使用的，也就是内核态。而普通的用户进程只能访问用户内存，如果需要使用系统资源，需要发起系统调用，也即转为内核态。内核态是对计算机资源的保护。Linux 磁盘IO方式1.基于中断的IO用户进程发起IO请求，进入内核态。cpu向硬件设备发送IO指令，随后cpu挂起当前进程，调度其他进程执行。当硬件设备处理完成后，发送中断信号给cpu，中断具有最高优先级，cpu会挂起当.

作为软件开发者特别是server开发，平时要面对大量的跨进程交互场景，各种跨进程调用。虽然现在的开发语言为我们提供了很好的封装，不用过度关心底层网络io的细节，但是作为开发者，还是要了解基本的原理。我们面对的是一个个黑盒，但是为了排查问题或者写出性能更好的程序，必须当成白盒来研究。Linux IO 模型。看看到掘金上的一篇文章，做一个笔记吧。https://juejin.cn/post/6892687008552976398https://www.jianshu.com/p/486b0965c2

答案是不一定，怎么看这个问题呢？1.从操作系统多核角度来看，多线程可以利用现代操作系统多核并行处理的优势，所以从这个角度来说，多线程会提高性能。2.如果只针对一个cpu看，cpu密集型的程序，多线程肯定没有单线程效率高。因为线程本身是需要消耗资源，包括为各个线程分配的内存以及线程上下文切换时消耗的cpu资源。所以说纯cpu的程序，多线程效率会降低。但是，现实往往不会这么理想，当今世界，很多系统都需要经过网络io，所以并不是cpu密集型。当程序执行需要执行io操作时，cpu就会空闲下来，而io往往会比

先回顾下几个概念。阻塞 vs 非阻塞：指的是调用者线程会不会被阻塞。BIO就是一种阻塞io，如果没有就绪，调用者线程会被阻塞挂起。而NIO是非阻塞的。同步 vs 异步：指的是调用方式，同步调用可以理解为调用结果需要调用者主动获取，而异步调用则是使用回调/通知机制，将结果回调给调用者，调用者无需关心。可以看到，二者是两个维度的概念，没有绑定关系。同步调用可以是阻塞的也可以是非阻塞的，比如BIO和NIO。异步调用通常是非阻塞的，比如AIO。目前现状是BIO和NIO占绝大多数的场景，AIO却用的不

一直以为是日志系统的功能，今天发现是jvm实现的，参数是：OmitStackTraceInFastThrow，并且只针对特定5种异常开启。详见：https://www.javajike.com/article/1768.html

变更的过程：工作区->(1)->暂存区-(2)->commit发生在（1）：工作区相对于暂存区的变化。使用git diff，可以查看区别；使用git checkout，可以用暂存区恢复工作区；发生在（2）：暂存区相对于commit的变化。使用git diff --cached，可以查看区别；使用git reset HEAD，可以使用HEAD的已提交内容恢复暂存区，暂存区的变更将会返回到工作区；使用git rm = rm + git rm；使用git mv = mv + git a

git存储三种类型：commit、tree与blobblob指的是文件，一个文件的一个版本对应一个blob对象，比如v1的版本的a.txt文件是一个blob，然后对a.txt进行了修改，重新commit为v2版本后，会多一个v2版本的blob，也就是说同一个文件，有几个版本就有几个blob对象这里也引申一下git的存储机制。首先git需要管理版本，那么需要能够恢复到之前的版本，所以可以肯定的是需要存储整个git仓库的每一个版本，有两个思路，一是存diff；二是存全量文件，也就是存快照。git使用的是后

kafka位移机制broker维护消费者的消费位移信息，老的版本存储在zk上，新版本存储在内部的topic里。本质上，位移信息消费者自己维护也可以，但是如果消费者挂了或者重启，对于某一个分区的消费位移不就丢失了吗？所以，还是需要提交到broker端做持久化的。提交方式分为自动和手动。自动是默认的行为，当然可以通过配置覆盖关掉自动提交。自动提交是consumer以一个时间间隔周期性地提交offset，比如每隔5s提交一次。提交发生的时机是poll调用时，会将上一次消费的位移信息提交到broker。自动提

HashedWheelTimer是netty开发包里时间轮组件，可以用于提交延迟任务。Java里的Time组件也具备相同的功能，不过Time是基于优先队列实现的，相当于需要对所有的任务基于执行时间排个序，复杂度是logn。而HashedWheelTimer是另一种思想，预先放置一定数量的任务槽，任务提交时，根据延迟时间放入对应的槽位。工作线程利用sleep模拟tick，将到达的槽位里的任务取出，依次执行。极端情况下是On，如果槽位足够大，接近于O1。使用 public static void

/** * guava开发包里的Maps#transformValues方法可能会导致异常catch不住。当然不是说guava实现有bug，是指使用者很可能不了解其实现原理，导致问题发生。 * Maps#transformValues的实现是lazy的，也就是调用该方法生成的map不是替换value之后的map，而是原始value+transfer function的map，是一个内部实现类TransformedEntriesMap。 * 也就是说我们的transfe...

本来想自己搭建，结果各种error，放弃。。。（mysql太难用。。。没做过运维）使用传统的基于文件位置的方式：需要slave指定复制的文件和位置，可能不准，位置靠后会少日志，位置靠前可能冲突，但是宁可冲突也不能少，所以需要手动跳过，不太方便。基于GTID的模式，每一条master生成的binlog，会打上一个gtid，gtid的格式是serverid：txid。所以在集群里可以认为每一条事务的gtid是唯一的。slave执行时，会记录自己执行过的gtid集合。如果需要换主，就将自己的gtid集

protobuf中的消息定义需要指定类型，试想一下，如果需要一种通用的类型该怎么办？protobuf中提供了Any机制，可以让我们在protobuf定义中不指定具体类型，在运行时指定类型进行解析，有点类似编程语言里的泛型思想（姑且这么说吧。。。）message TestParams1 { uint32 id = 1; string name = 2;}message TestMsg7 { google.protobuf.Any pass_through = 1;}

protobuff是一种平台语言无关的消息序列化协议，相比于传统的json、xml，序列后的空间更小，但是无法自解释，需要结合额外的proto定义文件才能反序列化，当然这样也更安全。下面记录一下protobuff消息格式。protobuff消息序列化后是多个key-value对，每一个字段对应一个key-value对。key-value遵循如下格式：tag|type (length) datatag|type：tag指的是字段的序号，这个一旦定义就不能更改，否则无法解析。type用于标识key-

在计算机中，整数值通常有两种类型：32位以及64位，在Java中分别对应的是int和long，在C++中分别对应的是int32/uint32和int64/uint64。整型值按照二进制补码的形式存放。而且是定长的。也就是不论数值大小，类型一旦固定，占用的bit位数就是固定的。那么protobuff协议如何序列化一个整数值？protobuff使用Varints编码格式来编码整数，这个协议最大的特点是变长编码。怎么理解？也就是一个整数值编码后的字节数是不确定的，数值越小，占用的字节数也越少，比如127以