所有的框架源码，最怕的就是被debug

知乎上有个问题：学编程是理解就行呢还是全部背？

我的观点是：我是建议用debug的思维去做这个事情，并且写一些小的demo验证它。

我之前在知乎写过一篇回答,redis 为什么是单线程的？

我才不管的它是C语言，D语言，xxx语言写的。我想搞清楚它，那我就debug它,直接把整个redis在我的window11上运行起来。

所有的问题，最怕的就是被debug。

我就是想知道redis单线程是怎么回事，就算它是C语言实现的，照样debug。

所有的问题，最怕的就是被debug。

不管是Tomcat的请求处理流程，还是Spring Boot的自动装配机制，还是MyBatis的SQL执行链路，你只要肯在关键位置打个断点跑一遍，debug它，它就没有秘密可言。

况且现在AI这么强大，你甚至可以问，在哪个类的哪个方法设置断点，是最合适的。然后设置个断点。

写小demo验证

Thinking in Java这本书，它伟大的地方在于它总是能用极短的代码把一个语言特性暴露出来。你看完那几行demo，那个特性就理解了。

这个方法我们自己也可以用。

想搞清楚Spring的循环依赖是怎么解决的？写3个类，A注入B，B注入C，C注入A，跑起来，debug进DefaultSingletonBeanRegistry的getSingleton方法。

想搞清楚线程池的拒绝策略到底什么时候触发？写个demo：

Java 复制代码

// 核心线程2个，最大线程3个，队列容量1个
ThreadPoolExecutor pool = new ThreadPoolExecutor(
    2, 3, 60, TimeUnit.SECONDS,
    new ArrayBlockingQueue<>(1));

往里面提交5个任务，第5个就会触发拒绝策略。不需要背什么「核心线程满了放队列，队列满了开新线程，最大线程也满了才拒绝」，跑一次demo，这个流程自己就理解了。

想搞清楚HashMap在并发场景下的问题？两个线程同时put，debug进resize方法看扩容过程中的链表操作，数据覆盖是怎么发生的就大概知道了。。

写demo的关键是：把问题缩小到最小可验证单元。 不要搭一个完整的项目来验证一个小问题。3个类、5行配置就能说明白的事情，不需要搭一个完整的Spring Boot工程。

最近在知乎出了「应付6000万会员的秒杀系统专栏」和「几亿用户,百万并发的C端商品系统实战」专栏，感兴趣的可以订阅一下。至于知识星球的，可以搜：

它是一个能实际帮你解决难题的星球。有问题的，找知心的Sam哥，支持无限次语音一对一解决你遇到的难题。「另外后续我新写的所有对外的付费专栏，在星球内都是免费的，且可以拿到所有源代码。」

知识星球内后续将推出20+个付费专栏，覆盖电商全链路：

从前台选购到中后台结算，星球成员全部免费，后续新增也不额外收费。

我的知乎账号: