共计 1826 个字符，预计需要花费 5 分钟才能阅读完成。
你好呀，我是歪歪。
上周公布了《我试图通过这篇文章通知你，这行源码有多牛逼。》这篇文章。
文章中有这样的一段形容：
而后有个读者来问我：
是怎么把 JDK 源码中的一行代码给正文掉的？
这个问题的确不错，属于一个偶然用一下能起到奇效的源码调试技巧。所以我决定写个文章来阐明一下这个问题。
然而这个技巧的确十分的简略，简略到一句话就能说明确，所以正如题目说到的“短小精悍，简略粗犷，但足够好用”，这篇文章也会十分的短。
首先，把问题换个问法，既然我能把源码正文了，那阐明我能批改源码。所以，问题就变成了：我怎么去批改 JDK 的源码呢？
这个问题有很多个答复，然而我这里的答复很简略。把源码拷贝一份进去，原模原样的放一份到本人的我的项目中即可。
就像是这样：
而后你在应用的时候，间接用你 CV 过去的源码，就行了：
然而我个别应用这个办法的时候，CV 过去时，会把类名称重命名一下，以示辨别，其余的啥都不改。
反正不论怎么样吧，这样在你的我的项目外面有一份“源码”了，这个“源码”和 JDK 外面的源码截然不同，这样你就能轻易进行批改了。
比方，我在调用 put 办法的时候，加一点日志输入：
这样测试用例跑起来的时候，就能间接输入你增加的内容：
你都能增加代码了，正文代码，甚至是批改代码逻辑，那还不是手到擒来的事件吗？
对于一些比较复杂的场景，比方异步或者循环等等场景，当你想要在源码中退出输入语句不便进行学习和调试的时候，你就能够用到这招。
这就是我这篇文章要教你的一个对于 JDK 源码的调试技巧。
整体用途不大，然而当你能想到用它的时候，就是施展奇效的时候。
既然话题都到这里了，那么我再给你补充一个对于第三方框架的相似的调试技巧。
还是先举个例子。
比方我在我的项目中应用到了 @Async 注解，而后有一个自定义线程池，发动一个申请之后能够看到的确是应用了我的自定义线程池：
而后，问题就来了。
假如，我想让 @Async 注解反对 EL 表达式，也就是这样的写法：
目前，Spring 是不反对这样的配置的，当你这样配置并发动调用，会抛出这样的一个异样：
它会把 ${thread-pool.name} 认为是一个 Bean，而后 Spring 外面并没有这样的一个 Bean，所以抛出找不到 Bean 的异样。
那么怎么能力让 @Async 注解反对 EL 表达式呢？
我之前写过《难受，给 Spring 奉献一波源码。》这篇文章，外面用的就是这个案例，有趣味的话能够去看看，我就不开展说了。
在文章外面，通过剖析，咱们晓得只须要在 org.springframework.aop.interceptor.AsyncExecutionAspectSupport.findQualifiedExecutor(BeanFactory，String) 这个办法中，退出这几行代码就行了：
if (beanFactory instanceof ConfigurableBeanFactory) {EmbeddedValueResolver embeddedValueResolver = new EmbeddedValueResolver((ConfigurableBeanFactory)beanFactory);
qualifier = embeddedValueResolver.resolveStringValue(qualifier);
}然而我过后采取的计划是通过 idea 的 Evaluate Expression 性能：
通过评论区揭示，其实用 CV 大法，更加间接、不便。
同样的情理，间接把 AsyncExecutionAspectSupport 这个类粘到咱们本人的我的项目中去：
这里须要留神的是，要保障包名称也截然不同，因为这个办法的底层逻辑是基于类加载机制实现的。
这样，咱们就能针对咱们本人我的项目中的 AsyncExecutionAspectSupport 类进行批改：
再次发动调用，这事儿就算成了：
这个办法，实用于任何你能拿到源码的任何第三方框架。
尽管，很多第三方框架外面都会被动留下足够多的扩大点，以便使用者进行定制化开发。
所以我提供的这个办法如同用途并不是很大，然而我当年看 Dubbo 源码的时候，就是这样的看的。
就像是这样，在源码外面退出了大量的输入语句，而后基于输入语句去做剖析：
尽管当初想起来，更加正确的操作应该是基于它的 SPI 机制去做。
然而，管它呢，反正过后我就是靠这种旁门左道，也看的明明白白的。
好了，以上就本文的全部内容。
突出的就是一个短小精悍，简略粗犷，又足够好用。
玩去吧。
