佐杰的博客

原创 mysql中mylsam存储引擎和innodb存储引擎的区别

摘要：本文对比了MySQL中MyISAM和InnoDB两种存储引擎的差异。通过创建两张表(user_myisam和user_innodb)并插入数据，从文件组织、锁机制和崩溃恢复三个方面进行对比分析。结果显示：MyISAM采用表级锁且不支持事务，更新时阻塞全表查询；InnoDB支持行级锁，允许并发读写。文件存储方面，MyISAM生成三个独立文件，而InnoDB使用共享表空间。崩溃测试表明，MyISAM数据易损坏，而InnoDB具备崩溃恢复能力。这些差异直接影响数据库的并发性能和数据安全性。

原创 锁性能基准测试

Java多线程锁性能测试报告摘要：在Java 17环境下，对8种同步机制进行百万次操作测试。结果显示，单线程下同步代码块和专用锁对象性能最优（200M ops/s），多线程下分段锁表现最佳（25M ops/s）。ReentrantLock和StampedLock在高并发时吞吐量下降明显（约55M ops/s vs 5M ops/s）。同步静态方法在100线程时仍保持14.7M ops/s的吞吐量，而同步实例方法为11.9M ops/s。测试表明，不同场景下应选择合适的锁机制：低竞争时同步代码块最优，高并发时

原创 AtomicStampedReference解决方案

本文介绍了使用版本戳(stamp)机制解决并发编程中的ABA问题。通过AtomicStampedReference类，在每次修改时递增版本号，并在CAS操作中同时检查值和版本号。示例代码展示了账户余额的并发修改场景：ABA线程先将余额从100改为50又改回100，而转账线程在不知情的情况下尝试修改。由于版本号已变化(0→2)，转账操作失败，有效避免了ABA问题。最终输出显示尽管余额相同(100元)，但因版本号变化(2)，转账线程的CAS操作被正确拒绝。该机制确保了数据修改的可追溯性和并发安全性。

原创 什么是ABA问题？

ABA问题是CAS操作中因值被多次修改最终恢复原值而引发的并发问题。演示显示账户余额从100→50→100，线程1未能感知中间变化仍执行转账，导致非法操作被掩盖。解决方案是使用AtomicStampedReference添加版本戳来跟踪每次修改，确保数据变化的可观测性。该问题在金融、库存等场景可能造成严重后果。

原创 在 JDK 17 上完整观察 synchronized 锁升级过

摘要：本文通过代码演示了JDK 17中synchronized锁的完整升级过程。程序使用Unsafe类和JOL工具分析对象头信息，展示了从无锁状态(001)到偏向锁(101)、轻量级锁(000)，最终到重量级锁(010)的完整升级路径。每个阶段都输出了对象内存地址、Mark Word值和锁状态位，并提供了详细的二进制状态说明。特别处理了不同线程竞争时的锁状态变化，为理解Java锁机制提供了直观的观察方法。

原创 Hashmap为什么要保持两倍扩容

这使得hash & (capacity - 1)等价于取模运算hash % capacity，但速度快10倍以上。当元素数量超过 8 × 0.75 = 6 时触发扩容（当前6个元素，刚好达到阈值）使用公式：newIndex = hash & 15（因为16-1=15）例如容量10：9 → 二进制 01001，hash & 9不能均匀分布。1.5倍扩容：元素可能迁移到5个不同位置。新位置：11（原位置3 + 旧容量8）新位置：1（与原位置相同）新位置：3（与原位置相同）新位置：5（与原位置相同）

原创 HashMap寻址算法

本文提供了HashMap解决哈希冲突的图示解析，包含两个示意图展示哈希冲突的不同处理方式。同时附上了相关Java集合核心原理的源码地址，该源码位于GitHub仓库的collections/HashMap目录下，具体文件名为addressing.html，可供开发者参考学习HashMap的底层实现机制。

原创 异或运算的高位分析

本文介绍了HashMap的实现原理，包含两张示意图展示其内部结构，并提供了相关源码地址。图示展示了HashMap的存储结构和哈希冲突处理方式。源码位于GitHub仓库的java-core-principles项目中，具体路径为collections/HashMap/hashmap.html，可供开发者进一步研究HashMap的实现细节。内容简明扼要地呈现了HashMap的核心实现要素。

原创 03 Broker主从架构和集群模式

摘要：Broker主从架构包含Master和Slave节点，Master处理写操作和读请求，Slave作为只读节点分担消费请求。数据同步提供异步复制（高性能）和同步双写（强一致）两种模式。故障转移流程包括：NameServer检测Master宕机后标记Broker组不可写，将Slave升级为可读节点，消费者自动重连继续消费。该架构通过角色分工和自动故障转移实现高可用消息服务。

原创 02 NameServer是如何管理Broker集群的

摘要：RocketMQ的Broker通过注册与心跳机制（每30秒）向NameServer集群上报信息，NameServer使用RouteInfoManager管理路由元数据，包括Broker基础信息、Topic路由和存活状态。NameServer每10秒检测Broker活跃度，超时（120秒）则剔除故障节点并清理路由。客户端定期（30秒）从NameServer获取路由信息，支持高可用。NameServer采用去中心化设计，多节点独立运行，通过最终一致性和客户端自动切换实现容灾。

原创 RocketMQ架构设计与运行流程分析

原创 Docker镜像瘦身：从1.43G到22.4MB

从 DockerHub（官方 Docker 镜像注册表）中我们可以看到，基于 alpine-based 的 Node 镜像比基于 Ubuntu 的镜像小得多，而且它们的依赖程度非常低。因此，现在我们将引入多级构建的概念，以减少不必要的代码和依赖于我们的最终镜像。我们尝试使用 Nginx 这类更高效、更轻量级的服务器来运行资源应用程序，也可以尽可能提高其性能，并且减少镜像的量。在查询结果列表的顶部，是我们新创建的图像，在最右边，我们可以看到图像的大小。这样我们在最终的镜像中就不会有不必要的依赖和代码。

原创 charls基于夜神模拟器抓取安卓7.0应用程序https请求

然后把hash值.0移到安卓设备/system/etc/security/cacerts/里。接下来就把下载charls的证书 charls.pem 改名为生成的hash值.0。查看证书 已经到了系统证书下了。已经可以抓到https的包了。

原创 python迭代器

迭代器是迭代取值的工具，迭代是一个重复的过程，每次重复都是基于上一次的结果而继续的，单纯的重复并不是迭代。

原创 动手实现一个可发送短信随机密码的高安全性用户密码系统

现假设我们是某个社交网站，对于每个新来的用户，我们可能都需要注册之后，才能进行使用网站的功能，但是对于注册流程，可能每个网站的流程都不一样，假设我们社交网站的注册流程为，先填写用户名和手机号，点击注册之后，系统注册成功之后，会创建一个随机密码，通过短信发送给用户，以后用户可以用该密码进行登录，也可以自己修改密码，我们来看一下整体的业务流程图。通过ThreadLocal来实现高安全性用户密码系统发送随机密码案例。用一个异步方式去处理随机密码的生成和随机密码短信的下发的任务，请看下图。

原创 线程本地化存储如何保证线程安全

我们把代码还原到图中，int c = a + b，基本类型的局部变量是存在栈空间，而new Object()代码创建的的对象实例的确是存在虚拟机的堆空间里，但是Object object只是引用(reference)堆空间里的对象，重要的事情说三遍，是引用，是引用，是引用，而new Object()这个对象只有被当前线程的自己所引用，我们再来看下面这张图。因为变量不共享，就不存在线程安全问题。当方法返回的时候，方法对应的栈帧，也会在栈空间被弹出，同时，执行的方法和对应的栈帧是同生共死的关系。

原创 探秘提交任务到线程池后源码的执行流程

7]如果说线程池状态确实是RUNNING，也就是二次校验通过，那么就判断一下线程池里是否还有线程，通过WorkerCountOf(recheck) == 0来判断，如果返回true了，就说明当前线程池中是空的，没有线程。对于核心线程来说，他们可以无限制的等待着任务被获取并执行，而非核心的线程则是在有限的时间内获取任务，一旦Worker无法获取到任务，也就是要获取的任务为空，循环就会结束，Worker自己就会主动的去除掉在线程池中的应用，进而被回收掉并退出。这个方法实际上最终就是开启了新的线程去执行任务。

原创 分析线程池的构造过程，追踪核心成员变量

这部分线程给他们分配了一个keepAliveTime参数，意义在于，当没有可处理的任务时，让它们别急着回收，而是先等会儿，看有没有任务来了，如果有就去执行任务，否则就等达到了keepAliveTime之后，对工作线程进行回收。也就是上图中的“最大池maximumPool”的容量，它的作用在于，当核心线程数被任务占满，且其中的任务缓冲队列也满了的时候，让新提交的任务仍旧可以执行，不至于立马就被拒绝。如下图中的核心池Pool中的线程池的数量，代表的含义就是这里的corePoolSize，如图。

原创 如何避免重复创建线程？创建线程池的方式有哪些？各自优缺点有哪些？

这里还要强调的一点是，在Java语言中，当我们每创建一个线程的时候，Java虚拟机就会在JVM内存中创建出一个Thread对象，与此同时创建一个操作系统的线程，最终在系统底层映射的是操作系统的本地线程（Native Thread），在windows系统中是1对1映射（即一个Java线程映射一个操作系统线程），在Linux系统是N对M映射（即多个Java线程映射多个操作系统线程，N与M不完全相等），这里就仅做了解，不详细展开了，感兴趣的同学可以去看一下操作系统的线程部分的知识。这玩意儿也是要占用内存空间的。

原创 实现智能安防系统的报警功能（一）

这些产品都需要报警功能，一旦监察到异常，就会向报警中心服务器上传报警信息，然后由报警中心程序通知对应的人员或者系统进行处理。建立定时器，并每隔5秒发送一次心跳检查，如果与告警中心服务器的连接断开，则重新建立连接。HeartbeatTask()心跳检查，新建定时调度线程，每隔n秒去检查一次连接。init: 初始化报警服务，和报警服务器建立连接，并定时发送心跳信息。通过blocker去唤醒一个线程，与告警中心服务器建立连接。4、烟雾报警器、燃气探测器。3、门磁、人体探测器。

原创 如何解决百万交易系统转账过程中循环等待，性能太差的问题？

死锁” 是两个或两个以上的线程在执行过程中，互相持有对方所需要的资源，导致这些线程处于等待状态，无法继续执行。若无外力作用，它们都将无法推进下去，就进入了“永久”阻塞的状态。如上图所示：线程01获得了账户A的锁，且同时去尝试获取账户B的锁；但是，线程02已经获得了账户B的锁，所以，线程01只能等待。同样，线程02也无法获得账户A的锁（已被线程01获取），只能等待。于是，线程01和线程02都在等待对方持有的锁，且会无限期的等待下去，这就是我们所说的“死锁”了！

原创 线程在执行过程中的状态是如何流转的？

当线程的run()方法完成时，或者主线程的main()方法完成时，我们就认为它终止了。线程一旦终止了，就不能复生。所以，当这个线程要执行时，就必须调用这个对象的start()方法，将NEW 状态转换到 RUNNABLE 状态。线程执行完 run() 方法后，会自动转换到 TERMINATED 状态，当然如果执行 run() 方法的时候异常抛出，也会导致线程终止。我们为了验证线程run()后，会自动转到terminated状态，所以，使用thread.getState()方法来获取“线程状态”。

原创 数据库与缓存⼀致性⽅案

⾸先我们对于所有的DB操作都不去添加具体的删除缓存的操作，⽽是通过canal监听binlog的⽅式，待数据确认已提交到数据库后，通过监听的变化，解析出对应的数据后，过滤掉⾮增删改的binlog，然后通过常量类配置的需要处理数据⼀致性的相关表以及关键字段和缓存前缀key，进⾏组装出需要进⾏删除的缓存key。现有的业务场景下，都会涉及到数据库以及缓存双写的问题，⽆论是先删除缓存，再更新数据，或者先更新数据，再删除缓存，都⽆法保证数据的⼀致性。本身他们就不是⼀个数据源，⽆法通过代码上的谁先谁后去保证顺序。

原创 你们系统每天有多大访问量？每个服务高峰QPS多少？压测过服务最大QPS吗？

在自己负责的系统里 核心模块 开发一个简单的metrics统计机制，AtomicLong,，原子性，并发下数据统计准确，每个接口被调用的时候，可以对每个接口做一个metrics统计。任何一个开源系统 都需要对自己运行过程中各种请求量，每秒的请求量、成功次数、失败次数，在内存里做一个计数，他会给你开放一些端口号，只要请求这些端口号，就会把metrics统计返回。对每个接口 每天的请求使用atomicLong做一个计数，统计每天的请求次数。

原创 最新的G1垃圾回收器的工作原理，你能聊聊吗？

所以简单来说，G1可以做到让你来设定垃圾回收对系统的影响，他自己通过把内存拆分为大量小Region，以及追踪每个Region中可以回收的对象大小和预估时间，最后在垃圾回收的时候，尽量把垃圾回收对系统造成的影响控制在你指定的时间范围内，同时在有限的时间内尽量回收尽可能多的垃圾对象。然后在垃圾回收的时候，G1会发现在最近一个时间段内，比如1小时内，垃圾回收已经导致了几百毫秒的系统停顿了，现在又要执行一次垃圾回收，那么必须是回收上图中那个只需要200ms就能回收掉20MB垃圾的Region啊！

原创 什么情况下JVM内存中的一个对象会被垃圾回收？

有GC Roots引用的对象不能回收，没有GC Roots引用的对象可以回收，如果有GC Roots引用，但是如果是软引用或者弱引用的，也有可能被回收掉。其实这里比较常用的，就是强引用和软引用，强引用就是代表绝对不能回收的对象，软引用就是说有的对象可有可无，如果内存实在不够了，可以回收他。然后如果新生代里的对象越来越多，都快满了，此时就会触发垃圾回收，把新生代没有人引用的对象给回收掉，释放内存空间。所以说，只要你的对象被，方法的局部变量，类的静态变量给引用了，就不会回收他们。

原创 如果任务过多，队列积压怎么处理？

好了，相信大家已经对多路复用的IO模型已经有一个初步的认识了，那么我们现在把购物狂生活中一起构建出IO多路复用场景中的角色抽象成代码模型大概是什么样的。首先我们不妨来看看，这个在没有收到快递员信息的情况向下，让购物狂先静静的等待一会儿，如果收到快递小哥来电就可以在小区里的站点展开快递搜索的行为叫做select，也就是说select是一个阻塞方法，既然它是一个IO多路复用里的通用行为，那么自然就跟我们业务代码无关，肯定是有一个在这套模型里有拥有这个方法的接口或类。

原创 如何根据系统的业务场景需求定制自己的线程池？

自定义线程工厂，需要实现ThreadFactory接口，此处提供一个参考实现，如图5所示，大家可以根据这个代码样例进行扩展，实现自己的线程工厂，当然也建议大家多去阅读优秀的开源框架，比如Netty、Tomcat，它们都提供了优秀的自定义的线程工厂的实现。我们以I/O密集型任务为例，实现一个自定义线程池的案例，具体代码如图我们定义了一个订单同步线程池，指定核心线程数为CPU数量+1，最大线程数为CPU数量*2，并指定非核心线程数的存活时间为60s。

原创 如何利用线程池实现互联网验证码保护服务

并且发送短信本身属于跨网络服务调用，本质上是一种网络I/O操作，因此如果直接在业务主线程上直接同步阻塞式的调用验证码发送模块的发送短信接口，会影响到整个业务流程的处理效率，如果单位时间内大量用户涌入，会造成注册接口响应缓慢。因此我们考虑通过异步方式去进行验证码发送，在AsyncSmsVerificationCodePusher类中通过定义一个专门的验证码发送线程池来实现验证码短信的发送。当用户注册账户成功之后，需要发送短信验证码，因此账户注册流程中会调用验证码发送模块提供的验证码发送服务。

原创 每日百万交易的支付系统，如何设置JVM堆内存大小？

那么大体上你的脑子里可以出现的一个流动的模型，应该是每台机器一秒钟接收到30笔支付订单的请求，然后在“JVM的新生代里创建了30个支付订单的对象”，做了写入数据库等处理，接着1秒之后，这30个支付订单就处理完毕，然后对这些支付订单对象的引用就回收了，这些订单在JVM的新生代里就是没人引用的垃圾对象了。只要大家网购过，大概的流程都会非常的清晰，假设我们在一个APP或者一个网站里买东西，大体上都是对一些商品加到购物车里，然后下个订单，接着对订单进行支付，钱从我们的账户划拨到人家网站的账户里去，大致如此。

原创 使用无界队列的线程池，在远程服务异常的情况下导致内存飙升怎么办？

只要有一个Worker异常挂掉，此时就会把这个worker从线程池里给挪出去，然后判断一下，如果当前线程数量 < corePoolSize，就会重新创建一个Worker和线程放入线程池中，自己再搞一个补位。可以考虑自己定制线程池，使用有界队列，不要使用无界队列，可以限制内存空间的使用，避免系统崩溃；无界队列，直接支撑前端的请求，不允许有界阻塞，到最后大不了就是系统崩溃。如果你提交到线程池的任务报错了，抛了异常出来，在线程池执行的过程中，Worker层面接收到一个异常，会直接throw抛出去。

原创 设计一套Kafka到RocketMQ的双写+双读技术方案，实现无缝迁移！

同时你要观察一段时间，当你发现持续双写和双读一段时间之后，如果所有的Consumer系统通过对比发现，从Kafka和RocketMQ读取和处理的消息数量一致，同时处理之后得到的结果也都是一致的，此时就可以判断说当前Kafka和RocketMQ里的消息是一致的，而且计算出来的结果也都是一致的。当你的双写持续一周过后，你会发现你的Kafka和RocketMQ里的数据看起来是几乎一模一样了，因为MQ反正也就保留最近几天的数据，当你双写持续超过一周过后，你会发现Kafka和RocketMQ里的数据几乎一模一样了。

原创 一次没有WHERE条件的SQL语句引发的OOM问题排查实践！

所以看到这一步基本就很明确了，就是Tomcat的工作线程处理一个请求的时候，发起了一个SQL语句，查出来了大量的数据，每条数据是一个HashMap，就是这大量的数据导致了系统的OOM。采用上述方法，当时我们对生产案例进行追踪，立马就定位到了是系统中的一个业务方法，在执行查询操作的时候，因为没有带上WHERE条件，直接查询出来了全部的上百万的数据，导致了内存的溢出。此时我们可以进入第二步，你可以深入的看看占用内存过多的对象是被谁引用的，哪个线程引用的，他们里面都是什么东西。

原创 解释一下什么是Young GC和Full GC？

2、Full GC？Old GC？傻傻分不清楚3、Full GC4、Major GC5、Mixed GC。

原创 如何解决电商平台中的商品分析系统分析热点商品过慢问题？

对于运营人员来说，需要统计的时间范围是灵活多变的，也许是统计某天，或者某几天内的热门商品列表。如果能更快地进行统计，根据其结果调整商品的展示策略，以及提前准备充足的库存，将会使收益最大化。但是由于我们统计的实在是太慢了，统计结果将无法及时呈现，也错过了最佳投放时间和备货时间，造成商品库存供应不及时。文件的读取和分析是串行的，也就是说，只有当一个日志文件处理完成之后，才会对下一个日志文件进行处理。该工具的统计依据是系统接口运行时产生的请求日志文件，它记录了收到请求的类型、商品的ID、请求时间戳等。

原创 如何解决移动互联网短网址转换失败造成数据丢失问题？

上面的代码了给出了长网址转换为短网址的做法，但是如果要将短网址转化为长网址要怎么实现了？其实很简单，在上面的长短网址转换服务中，将长网址转换为短网址完成后，立马将长短网址的映射关系保存起来，比如保存到数据库中。然后用户访问时传递短网址地址，服务端会先去地址转换服务查询对应的长网址，对于地址转换服务的逻辑处理也很简单，直接去数据库里查询长短网址映射表，根据当前的短连接查询出对应的长网址。比如，用户在某网站发布一篇图文，那么肯定会生成该图文对应的长网址，同时大多数网站还会有一个对应的短网址，如图1。

原创 如何解决互联网房产交易合同管理平台的性能低下问题？

对于平台最初的版本来说，为了赶进度，我们简单实现了这个合同上传的功能即可，不需要考虑太多性能问题。而且一开始用户量并不是很大，问题不会很大。但随着公司不断投入广告，对平台进行大力推广，用户量不断增多，这个时候，性能问题也会日渐严峻了。对于互联网产品，用户体验非常重要，因此对这个平台进行性能优化迫在眉睫。那具体要怎么来优化才好呢？

原创 网关压测对比

况下压测的结果变化，压测结果有可⽐性；同时输出dstat -v。Nginx、SpringCloud Gateway 压测对比。每个场景都输出⼀个基本压测结果，然后在输出不同参数配置情。系统指标情况，查看JVM GC情况进⾏调优。

原创 docker 版 mysql 主从同步

【代码】docker 版 mysql 主从同步。

原创 sysbench压测自装MySQL数据库

【代码】sysbench压测自装MySQL数据库。