本文字数：7190 字，阅读完需：约 5 分钟

大家好，我是 shixin。

一转眼，我从事安卓开发工作已经六年有余，对安卓开发甚至软件开发的价值，每年都有更进一步的认识。对未来的方向，也从刚入行的迷茫到现在逐渐清晰。我想是时候做一个回顾和展望了。

这篇文章会先回顾我从入行至今的一些关键点，然后讲一下经过这些年，我对软件开发的认知变化，最后分享一下后面的规划。

回顾

人太容易在琐碎生活中迷失，我们总是需要记住自己从哪里来，才能清楚要到哪里去。

入行至今的一些关键节点

2014～2015：开始安卓开发之旅

说起为什么做安卓开发，我很有感慨，差一点就“误入歧途”😄。

当初在大学时，加入了西电金山俱乐部，俱乐部里有很多方向：后端、前端、安卓、Windows Phone 等。

由于我当时使用的是三星 i917，WindowsPhone，所以就选了 WinPhone 方向。

当时还是 iOS、安卓、WinPhone、塞班四足鼎立的时代，WinPhone 的磁贴式设计我非常喜欢，加上设备的流畅性、像素高，一度让我觉得它可能会统治移动市场。

结果在学习不到 2 个月以后，我的 WinPhone 意外进水了！我当时非常难过，一方面是对手机坏了的伤痛，另一方面也是对无法继续做 WinPhone 开发很遗憾。对于当时的我来说，再换一台 WinPhone 过于昂贵，只好换一台更加便宜的安卓机，因此也就转向学习安卓开发。

后面的故事大家都知道了，因为 WindowsPhone 缺乏良好的开发生态，支持应用很少，所以用户也少，用户少导致开发者更少，恶性循环，如今市场份额已经少的可怜。

现在回想起来，对于这件事还很有感慨，有些事当时觉得是坏事，拉长时间线去看，未必是这样。

当时还有一件目前看来非常重要的决定：开始写博客，记录自己的所学所得。

在开发项目时，我经常需要去网上搜索解决方案，后来搜索的多了，觉得总不能一直都是索取，我也可以尝试去写一下。于是在 CSDN 注册了账号，并于 2014 年 10 月发布了我的第一篇原创文章。

后来工作学习里新学到什么知识，我都会尽可能地把它转换成别人看得懂的方式，写到播客里。这个不起眼的开始，让我逐渐有了解决问题后及时沉淀、分享的习惯，受益匪浅。

2015～2017：明白项目迭代的全流程

在学习安卓开发时，我先看了一本明日科技的《Android 从入门到精通》，然后看了些校内网的视频，逐渐可以做一些简单的应用。安卓开发所见即所得的特点，让我很快就可以得到正反馈。后来又去参加一些地方性的比赛，获得一些名次，让我逐渐加强了从事这个行业的信心。

在 2015 年时，偶然参加了一家公司的招聘会，在面试时，面试官问了一些简单的 Java 、安卓和算法问题。其中印象最深的就是会不会使用四大组件和 ListView。在当时移动互联网市场飞速发展时，招聘要求就是这么低。以至于现在很多老安卓回忆起当初，都很有感慨：“当初会个 ListView 就能找工作了，现在都是八股文” 哈哈。

到公司实习后，我感触很多，之前都是自己拍脑袋写一些简单的功能，没有开发规范、发布规范，也没有工程结构设计、系统设计，更没有考虑性能是否有问题。真正的去开发一个商业项目，让我发现自己不足的太多了。

因此在完成工作的同时，我观察并记录了项目迭代的各个流程，同时对自己的技术点做查漏补缺，输出了一些 Java 源码分析、Android 进阶、设计模式文章，也是从那个时候开始，养成了定期复盘的习惯，每次我想回顾下过去，都会看看我的成长专栏。

2017～2020：提升复杂项目的架构能力和做事意识

第一个项目中我基本掌握了从 0 到 1 开发一个安卓应用的流程，但对安卓项目架构还只停留在表面，没有足够实践。

在 2017 年，我开始做喜马拉雅直播项目，由于喜马拉雅在当时已经有比较多年的技术积累，加上业务比较复杂，在架构设计、编译加速、快速迭代相关都做了比较多的工作，让我大饱眼福。

同时直播业务本身也是比较复杂的，在一个页面里会集成 IM、推拉流等功能，同时还有大量的消息驱动 UI 刷新操作，要保证业务快速迭代，同时用户体验较好，需要下不少功夫。

为了能够提升自己的技术，在这期间我学习了公司内外很多框架的源码，通过分析这些框架的优缺点、核心机制、架构层级、设计模式，对如何开发一个框架算是有了基本的认识，也输出了一些文章，比如 《Android 进阶之路：深入理解常用框架实现原理》。

有了这些知识，再去做复杂业务需求、基础框架抽取、内部 SDK 和优化，就容易多了。

在开发一些需求或者遇到复杂的问题时，我会先想想，之前看的这些三方框架或者系统源码里有没有类似的问题，它们是怎么解决的？ 比如开发 PK 功能，这个需求的复杂性在于业务流程很多，分很多状态，咋一看好像很复杂，但如果了解了状态机模式，就会发现很简单。借用其他库的设计思路帮我解决了很多问题，这让我确信了学习优秀框架源码的价值。

除了技术上的提升，在这几年里，我的项目全局思考能力也提升很多。

由于我性格外向，和各个职能的同学沟通交流比较顺畅，领导让我去做一个十人小组的敏捷组长，负责跟进需求的提出、开发、测试、上线、运营各个环节，保证项目及时交付并快速迭代。

一开始我还有些不习惯，写代码时总是被不同的人打断，比如产品需求评审、测试 bug 反馈、运营反馈线上数据有问题等等，经常刚想清楚代码怎么写，正准备动手，就被叫去开会，回来后重新寻找思路。

后来在和领导沟通、看一些书和分享后，逐渐对写代码和做事，有了不同的认识。代码只是中间产物，最终我们还是要拿到对用户有价值、给公司能带来收入的产品，要做到这个，眼里除了代码，还需要关注很多。

2020～至今：深入底层技术

在进入字节做基础技术后，我的眼界再一次被打开。

字节有多款亿级用户的产品，复杂的业务常常会遇到各种意想不到的问题，这些问题需要深入底层，对安卓系统的整个架构都比较熟悉，才能够解决。

上图是安卓系统架构图，之前我始终停留在一二层，在这一时期，终于有了纵深的实践经验。

比如帮业务方解决一个内存问题，除了要了解内存指标监控方式，还要知道分析不同类型内存使用的工具及基本原理，最后知道是哪里出了问题后，还要想如何进行体系化的工具，降低学习成本，提升排查效率。

问题驱动是非常好的学习方式。每次帮助业务解决一个新问题，我的知识库都会多一个点，这让我非常兴奋。之前不知道学来干什么的 Linux 编程、Android 虚拟机，终于在实际问题中明白了使用场景，学起来效率也高了很多。

对软件开发的认识

前面讲了个人的一些经历，包括我怎么入的行，做了什么项目，过程中有什么比较好的实践。下面讲一下我从这些具体的事里面，沉淀出哪些东西有价值的结论。

主要聊下对这两点的认识：

• 职业发展的不同阶段

• 技术的价值

职业发展的不同阶段

第一点是对职业发展的认识。我们在工作时，要对自己做的事有一个清晰的认识，它大概属于哪一个阶段，怎样做可以更好。

结合我这些年的工作内容、业内大佬所做的事情，我把软件开发者的职业发展分这几个阶段：

1. 使用某个技术方向的一个点开发简单项目

2. 使用某个技术方向的多个点及某条线，开发一个较为复杂的业务或系统

3. 掌握某个方向的通用知识，有多个线的实践，可以从整体上认识和规划

4. 不限于该方向，能从产品指标方面出发，提供全方位的技术支持业务角度，端到端关注指标

第一个阶段就是使用某个技术方向的一个点完成业务需求。拿安卓开发者来说，比如使用 Android SDK 自定义布局，完成产品要求的界面功能。这个阶段比较简单，只要能够仔细学习官方文档或者看一些书即可胜任。拿后端来说，比如刚接手一个小项目，日常工作就是使用 Spring 等库开发简单的接口，不涉及到上下游通信、数据库优化等。

第二个阶段，你做的项目更加复杂了，会涉及到一个技术方向的多个点，这时你需要能把这些点连起来，给出一个更体系化的解决方案。

拿安卓开发者来说，比如在自定义布局时，发现界面很卡顿，要解决这个问题的话，你就要去了解这个自定义 View 的哪些代码流程影响了这个页面的刷新速度。这就相当于是从一个点到另一个点。怎么连起来呢？你需要去研究渲染的基本原理，分析卡顿的工具，找到导致卡顿的原因，进行优化。这个过程会对流畅性有整体的认识，能够对相关问题有比较全面的分析思路、解决手段，从而可以开发相关的分析工具或优化库。 如果能达到这个程度，基本就算是一个高级工程师了，不只是做一个模块，还能够负责一个具体细分方向的工作。

第三个阶段，掌握某个技术方向的通用知识，有多个线的实践，能够连线为面，同时给工作做中长期的技术规划。

拿安卓开发来说，刚才提到你通过解决卡顿问题，在流畅性这方面有了比较多的实践；然后你又发现内存有问题，去了解了内存分配、回收原理，做出内存分析优化工具，这样就也有了内存的一个体系化的实践。再加一些其他的优化经验，比如启动速度、包大小等。把这些线连起来，就得到了一个性能监控平台，这就是有把多条线连成一个面。

还有比如说你发现项目打包和发布过程中的一些痛点，并且能够做一些实践解决，最后如果能够把这些优化项连起来做一个统一的系统，给出完整的 DevOps 方案，提升开发、发布、运维的效率。能够把这个系统搭建起来，有比较深入的经验，那就可以成为“技术专家”了。

再往上走就不只是做技术，而要更多思考业务。技术最终都是要为业务服务。职业发展的第四个阶段，就是不局限于某个技术方向，能够从产品的业务规划、业务指标出发，给产品提供技术支持。

你首先要明白公司业务的核心指标是什么，比如说拿一个短视频应用来说，它核心指标除了常规的日活、用户量，还更关注视频的播放率、停留时长、页面渗透率等。了解这些指标以后，你要思考做什么可以有助于公司提升这些指标。结合业务指标反思当前的项目哪里存在优化空间。

有了这个思路并且知道可以做什么以后，你可以做一个较为全面的规划，然后拉领导去讨论可行性。这时你不能再局限于某一端，不能说我只是个安卓开发，其他部分都找别人做。一般在项目的价值没有得到验证之前，领导不会轻易给你资源，因此第一个版本迭代肯定是要靠你自己，从前到后独立完成，做一个 MVP 版本，然后让领导认可了这个系统的价值，才有可能会分给你更多的资源做这件事。

总结一下对职业发展的认识：第一阶段只做一些具体的点；第二阶段做多个点，需要能够连点成线；第三个阶段需要围绕这些线提炼出通用的知识，然后做到对业务/技术项目有整体的认识；第四阶段能够从业务指标出发，做出有价值的系统/平台。

技术的价值

说完职业发展的不同阶段，接下来聊下技术对业务的价值。

技术是为业务服务的。根据业务的不同阶段，技术的价值也有所不同：

1. 业务从 0 到 1 时，帮助业务快速确定模式

2. 业务从 1 到 100 时，帮助业务快速扩大规模

3. 最卓越的，用技术创新带动业务有新的发展 （Google、AWS、阿里云）

业务从 0 到 1 时

我一开始做的工作，业务就是处于确定模式期间。业务上反复试错，项目常常推倒重来，会让程序员觉得很有挫败感。

这个阶段很多程序员都会发挥复制粘贴大法，产品经理说要新增一个功能，就复制一份代码稍微改一改。

如果说目前就是在这种业务中，该怎么做呢？如果我回到当时那个情景，我可以做什么让公司业务变得更好呢？

我总结了两点：在高效高质量完成业务的同时，思考如何让业务试错成本更低。

如何让业务试错成本更低呢？大概可以有这些方式：

• 提供可复用的框架

• 提供便捷的数据反馈机制

• 多了解一些竞品业务，在产品不确定的时候，给一些建议

第一点：尽可能的抽象相似点，减少重复成本。

如果产品每次都给你类似的需求，你可以考虑如何把这些重复需求抽象成一些可以复用的逻辑，做一个基本的框架，然后在下次开发的时候能够去直接用框架，而不是每次都从头开始。我平时工作也常常问自己“我现在做的事有哪些是重复的，哪些是可以下沉的”。

就安卓开发来说，这个阶段，可以做好基础建设，提供插件化、热修复、动态化框架，帮助业务快速发版，自研还是第三方看公司财力。

如果你说这些太复杂了我做不来，那就从更小的层面做起，比如某个功能原本需要多个接口多个界面，看能不能改成接口参数可配置，界面根据参数动态生成（也就是 DSL）。

第二点：提供便捷的数据反馈机制。

在产品提需求时，你可以问问产品这个需求出于什么考虑，有没有数据支撑？比如说产品需求是某个按钮换个位置，那你要搞清楚，为什么要换，换完之后会导致页面打开率提升吗？要有这种数据驱动的理念。

如果公司做决策时缺乏相应的数据，你可以主动地去提供这种数据反馈机制。比如说开发一个埋点平台、数据监控平台。尽可能地让业务有数据可看，能够数据驱动，而不是像无头苍蝇一样盲目尝试。

如果无法做一个这么大的系统，那可以先从力所能及的做起，比如说战略上重视数据；做好数据埋点；思考做的功能，目前有哪些数据是核心的，这些数据有没有上报，不同版本的数据是升还是降等。

好，这是第一个阶段，技术对业务价值就是帮助业务快速确定模式。第二个阶段就是业务快速扩大规模时，技术的核心价值是什么呢？

业务从 1 到 100 时

业务正在快速扩大规模时，需要把当前跑通的业务模式复制到更多的地方，同时能够服务更多的用户。这个阶段，技术能够提供的价值主要是两点。

1. 快速迭代（这一点其实无论什么阶段）

2. 提升质量（用户规模日活上亿和日活一万，需要面对的挑战差异也是这个数量级）

第一点：快速迭代

虽然快速迭代是业务各个阶段都需要做到，但和从 0 到 1 相比，从 1 到 100 的阶段会有更多的挑战，除了个人速度，更要关注团队的速度。

团队的速度如何提升？可以参考后端的单体到微服务、前端的单仓到多仓的演变过程及原因。

这个阶段主要有这几点问题：

1. 多人协作代码冲突

2. 发布速度慢

3. 出问题影响大，不好定位

具体到安卓项目，几百人开发和三两个人开发的，复杂度也是几百倍。我们可以做的是：

1. 下沉基础组件，定义组件规范，收敛核心流程

2. 拆分业务模块，设计业务模板，单独维护迭代

3. 探索适合业务的新方式：跨端（RN Flutter KotlinMultiplatform）、动态化、多端逻辑一致（C/C++ Rust）

第二点：提升质量

和日活几万的项目相比，日活千万甚至上亿的产品，需要应对的质量问题更加显著。在这个阶段，我们不仅要满足于实现功能，还要能够写的好，更要能够了解底层原理，才能应对这样大的业务量。

有了大规模的用户后，你会遇到很多奇怪的问题，不能疲于每天去解决一样重复的问题，那你就需要从这些问题中找到一些共通的点，然后提炼出来，输出工具、解决方案甚至平台。

这就需要你从问题中磨练本领，站在更高的层面思考自己该具体的能力、思路和工具。

在解决问题的时候，除了当下这个问题，更需要做的是把这个问题解构、归类，抽象出不同问题的相似和差异，得出问题分析流程图。

同样是分析内存泄漏，有的人可能只知道使用 Leakcanary，但你还可以思考的更深入，比如：

• 先定义问题。什么是泄露？

• 泄露是申请了没有释放或者创建了没有回收

• 内存泄露怎么分析？

• 找到创建和销毁的点

• 在创建的时候保存记录，销毁的时候删除这个记录，最终剩下来的就是泄露的

有了基础的逻辑，就可以把它套用到各种问题上：

• Native 内存泄漏：在 Native 内存分配和释放 API，做记录

• 图片使用不当：在图片创建、释放的 API 里做记录

• 线程过多：在线程创建、释放的 API 里做记录

在遇到一个新问题时，发现和之前解决过的有点像，但又不知道哪里像。怎么办？回头去思考新旧的两个问题，它们的本质是什么？有什么相似的分析思路？

这个思考训练的目的，就是提升举一反三的能力。大规模应用可能各种问题，需要你一方面提升技术，另一方面分析问题的思路和能力上也要提升，不能看着一个问题就是一个问题，要做到看到一个问题，想到一类问题。

展望（后面的规划）

技术上达到一专多能，软实力上持续提升。

硬实力

专业

如果你是安卓开发，最好在某个有细分领域很擅长，比如音视频、跨端、动态化、性能优化。

我目前主要是做优化，后面需要继续补充的知识：

• Linux 内核原理

• Android 虚拟机原理

• 项目从开发、编译、发布、数据分析各个流程的效率提升方式

多能

前面提到职业发展的第四个阶段：

不限于该方向，能从产品指标方面出发，提供全方位的技术支持

我希望可以具备独立完成一个系统从前到后的能力。

目前已有的经验：

• 使用 TypeScript + React + Electron 开发桌面端软件

• 使用 SpringMVC 开发简单的内部系统

后面需要加强的点：

• 熟练掌握前端的 JS、打包、优化等知识

• 后端技术达到中级

还有这些点需要长期关注：

• Flutter 更新频繁，有一些尝试效果还不错，一套代码多端运行，节省开发成本

• 掌握 DevOps 理念及实践

最终目的：

• 具备独立完成一个有价值的系统的能力

• 具备对研发整个流程的完善、优化能力

软实力

除了技术规划，我也有很多软实力需要继续提升，今年主要想提升的就是同频对话的能力。

什么是同频对话？

同频对话就是根据听众的角色和他的思考角度去转换你的表达内容。

比如说我们在和领导汇报的时候，你要去讲你做的一个系统，你就要从他角度去表达。他可能关注的是整体流程、系统的难点、瓶颈在哪里，带来的收益是什么。那你就不能只讲某个模块的细节，而要从更高的层面去思考和表达。

为什么要提升呢？

随着工作年限的增加，市场对我们的要求是越来越高的，除了写代码，对表达能力的要求也是越来越高的。

一开始刚入行，你就是做一个执行者，只要多动耳朵、眼睛、手，实现别人要求你做的功能。

后来你的能力逐渐提升以后，有机会设计一个模块的时候，你就需要多动脑力去思考，去复设计这个系统的输入输出、内部数据流转等。

再往后走的话，你可能会有一些资源，那就需要能把你的想法完整地表达出来，让别人帮你去贯彻落地。这其实是一种比较难得的能力。我今年计划通过多分享、多与不同的人交流等方式，提升自己的这种能力，争取做到满意的程度。

结束语

好了，这篇文章就到这里了，这就是我这六年的技术回顾和展望，感谢你的阅读❤️。

人生的多重境界：看山是山、看水是水；看山不是山、看水不是水；看山还是山、看水还是水。

我想，我对软件开发，还没有达到第三层，相信用不了多久，就会有不同的观点冒出来。

但，怕什么真理无穷，进一寸有一寸的欢喜！

作者：张拭心
来源：juejin.cn/post/7064960413280141348

事情是这样的

下面是我朋友的面试记录：

面试官：讲一下你实习做了什么。

朋友：我在实习期间做了一个存储用户操作记录的功能，主要是从MQ获取上游服务发送过来的用户操作信息，然后把这些信息存到MySQL里面，提供给数仓的同事使用。由于数据量比较大，每天大概有四五千多万条，所以我还给它做了分表的操作。每天定时生成3张表，然后将数据取模分别存到这三张表里，防止表内数据过多导致查询速度降低。

这表述，好像没什么问题是吧，别急，接着看：

面试官：那你为什么要分三张表呢，两张表不行吗？四张表不行吗？

朋友：因为MySQL每张表最好不超过2000万条数据，否则会导致查询速度降低，影响性能。我们每天的数据大概是在五千万条左右，所以分成三张表比较稳妥。

面试官：还有吗？

朋友： 没有了…… 你干嘛，哎呦

面试官：那你先回去等通知吧。

🤣🤣🤣讲完了，看出什么了吗，你们觉得我这位朋友回答的有什么问题吗？

前言

一般来说，MySQL每张表最好不要超过2000万条数据，否则就会导致性能下降。阿里的Java开发手册上也提出：单表行数超过 500 万行或者单表容量超过 2GB，才推荐进行分库分表。

但实际上，这个2000万或者500万都只是一个大概的数字，并不适用于所有场景，如果盲目的以为表数据只要不超过2000万条就没问题了，很可能会导致系统的性能大幅下降。

实际情况下，每张表由于自身的字段不同、字段所占用的空间不同等原因，它们在最佳性能下可以存放的数据量也就不同。

那么，该如何计算出每张表适合的数据量呢？别急，慢慢往下看。

本文适合的读者

阅读本文你需要有一定的MySQL基础，最好对InnoDB和B+树都有一定的了解，可能需要有一年以上的MySQL学习经验（大概一年？），知道 “InnoDB中B+树的高度一般保持在三层以内会比较好”。

本文主要是针对 “InnoDB中高度为3的B+树最多可以存多少数据” 这一话题进行讲解的。且本文对数据的计算比较严格（至少比网上95%以上的相关博文都要严格），如果你比较在意这些细节并且目前不太清楚的话，请继续往下阅读。

阅读本文你大概需要花费10-20分钟的时间，如果你在阅读的过程中对数据进行验算的话，可能要花费30分钟左右。

基础知识快速回顾

众所周知，MySQL中InnoDB的存储结构是B+树，B+树大家都熟悉吧？特性大概有以下几点，一起快速回顾一下吧！

注：下面这这些内容都是精华，看不懂或者不理解的同学建议先收藏本文，之后有知识基础了再回来看 。🤣🤣

1. 一张数据表一般对应一颗或多颗树的存储，树的数量与建索引的数量有关，每个索引都会有一颗单独的树。

2. 聚簇索引和非聚簇索引：

   主键索引也是聚簇索引，非主键索引都是非聚簇索引，两种索引的非叶子节点都是只存索引数据的，比如索引为id，那非叶子节点就只存id的数据。

   叶子节点的区别如下：

   • 聚簇索引的叶子节点存的是这条数据的所有字段信息。所以我们 select * from table where id = 1 的时候，都是要去叶子节点拿数据的。

   • 非聚簇索引的叶子节点存的是这条数据所对应的主键信息。比如这条非聚簇索引是username，然后表的主键是id，那该非聚簇索引的叶子节点存的就是id，而不存其他字段。 相当于是先从非聚簇索引查到主键的值，再根据主键索引去查数据内容，一般情况下要查两次（除非索引覆盖），这也称之为 回表 ，就有点类似于存了个指针，指向了数据存放的真实地址。

3. B+树的查询是从上往下一层层查询的，一般情况下我们认为B+树的高度保持在3层是比较好的，也就是上两层是索引，最后一层存数据，这样查表的时候只需要进行3次磁盘IO就可以了(实际上会少一次，因为根节点会常驻内存)。

   如果数据量过大，导致B+数变成4层了，则每次查询就需要进行4次磁盘IO了，从而使性能下降。所以我们才会去计算InnoDB的3层B+树最多可以存多少条数据。

4. MySQL每个节点大小默认为16KB，也就是每个节点最多存16KB的数据，可以修改，最大64KB，最小4KB。

   扩展：那如果某一行的数据特别大，超过了节点的大小怎么办？

   MySQL5.7文档的解释是：

   • 对于 4KB、8KB、16KB 和 32KB设置 ，最大行长度略小于数据库页面的一半 ，例如：对于默认的 16KB页大小，最大行长度略小于 8KB 。

   • 而对于 64KB 页面，最大行则长度略小于 16KB。

   • 如果行超过最大行长度， 则将可变长度列用外部页存储，直到该行符合最大行长度限制。 就是说把varchar、text这种长度可变的存到外部页中，来减小这一行的数据长度。

   

   文档地址：MySQL :: MySQL 5.7 Reference Manual :: 14.12.2 File Space Management

5. MySQL查询速度主要取决于磁盘的读写速度，因为MySQL查询的时候每次只读取一个节点到内存中，通过这个节点的数据找到下一个要读取的节点位置，再读取下一个节点的数据，直到查询到需要的数据或者发现数据不存在。

   肯定有人要问了，每个节点内的数据难道不用查询吗？这里的耗时怎么不计算？

   这是因为读取完整个节点的数据后，会存到内存当中，在内存中查询节点数据的耗时其实是很短的，再配合MySQL的查询方式，时间复杂度差不多为 O(log2N)O(log_2N)O(log2N) ，相比磁盘IO来说，可以忽略不计。

MySQL B+树每个节点都存里些什么？

在Innodb的B+树中，我们常说的节点被称之为 页(page)，每个页当中存储了用户数据，所有的页合在一起组成了一颗B+树（当然实际会复杂很多，但我们只是要计算可以存多少条数据，所以姑且可以这么理解😅）。

页 是InnoDB存储引擎管理数据库的最小磁盘单位，我们常说每个节点16KB，其实就是指每页的大小为16KB。

这16KB的空间，里面需要存储 页格式 信息和 行格式 信息，其中行格式信息当中又包含一些元数据和用户数据。所以我们在计算的时候，要把这些数据的都计算在内。

页格式

每一页的基本格式，也就是每一页都会包含的一些信息，总结表格如下：

示意图：

页格式这块的内容，我在官网翻了好久，硬是没找到🤧。。。。不知道是没写还是我眼瞎，有找到的朋友希望可以在评论区帮我挂出来😋。

所以上面页格式的表格内容主要是基于一些博客中学习总结的。

另外，当新记录插入到 InnoDB 聚集索引中时，InnoDB 会尝试留出 1/16 的页面空闲以供将来插入和更新索引记录。如果按顺序（升序或降序）插入索引记录，则生成的页大约可用 15/16 的空间。如果以随机顺序插入记录，则页大约可用 1/2 到 15/16 的空间。参考文档：MySQL :: MySQL 5.7 Reference Manual :: 14.6.2.2 The Physical Structure of an InnoDB Index

除了 User Records和Free Space 以外所占用的内存是 38+56+26+8=12838 + 56 + 26 + 8 = 12838+56+26+8=128 字节，每一页留给用户数据的空间就还剩 16×1516×1024−128=1523216 \times \frac{15}{16} \times 1024 - 128 = 1523216×1615×1024−128=15232 字节（保留了1/16）。

当然，这是最小值，因为我们没有考虑页目录。页目录留在后面根据再去考虑，这个得根据表字段来计算。

行格式

首先，我觉得有必要提一嘴，MySQL5.6的默认行格式为COMPACT(紧凑)，5.7及以后的默认行格式为DYNAMIC(动态)，不同的行格式存储的方式也是有区别的，还有其他的两种行格式，本文后续的内容主要是基于DYNAMIC(动态)进行讲解的。

官方文档链接：MySQL :: MySQL 5.7 参考手册 :: 14.11 InnoDB 行格式（包括下面的行格式内容大都可以在里面找到）

每行记录都包含以下这些信息，其中大都是可以从官方文档当中找到的。我这里写的不是特别详细，仅写了一些能够我们计算空间的知识，更详细内容可以去网上搜索 “MySQL 行格式”。

示意图：

另外还有几点需要注意：

溢出页（外部页）的存储

注意：这一点是DYNAMIC的特性。

当使用 DYNAMIC 创建表时，InnoDB 会将较长的可变长度列（比如 VARCHAR、VARBINARY、BLOB 和 TEXT 类型）的值剥离出来，存储到一个溢出页上，只在该列上保留一个 20 字节的指针指向溢出页。

而 COMPACT 行格式（MySQL5.6默认格式）则是将前 768 个字节和 20 字节的指针存储在 B+ 树节点的记录中，其余部分存储在溢出页上。

列是否存储在页外取决于页大小和行的总大小。当一行太长时，选择最长的列进行页外存储，直到聚集索引记录适合 B+ 树页（文档里没说具体是多少😅）。小于或等于 40 字节的 TEXT 和 BLOB 直接存储在行内，不会分页。

优点

DYNAMIC 行格式避免了用大量数据填充 B+ 树节点从而导致长列的问题。

DYNAMIC 行格式的想法是，如果长数据值的一部分存储在页外，则通常将整个值存储在页外是最有效的。

使用 DYNAMIC 格式，较短的列会尽可能保留在 B+ 树节点中，从而最大限度地减少给定行所需的溢出页数。

字符编码不同情况下的存储

char 、varchar、text 等需要设置字符编码的类型，在计算所占用空间时，需要考虑不同编码所占用的空间。

varchar、text等类型会有长度字段列表来记录他们所占用的长度，但char是固定长度的类型，情况比较特殊，假设字段 name 的类型为 char(10) ，则有以下情况：

• 对于长度固定的字符编码（比如ASCII码），字段 name 将以固定长度格式存储，ASCII码每个字符占一个字节，那 name 就是占用 10 个字节。

• 对于长度不固定的字符编码（比如utf8mb4），至少将为 name 保留 10 个字节。如果可以，InnoDB会通过修剪尾部空格空间的方式来将其存到 10 个字节中。

  如果空格剪完了还存不下，则将尾随空格修剪为 列值字节长度的最小值（一般是 1 字节）。

  列的最大长度为： 字符编码的最大字符长度×N字符编码的最大字符长度 \times N字符编码的最大字符长度×N，比如 name 字段的编码为 utf8mb4，那就是 4×104 \times 104×10。

• 大于或等于 768 字节的 char 列会被看成是可变长度字段（就像varchar一样），可以跨页存储。例如，utf8mb4 字符集的最大字节长度为 4，则 char(255) 列将可能会超过 768 个字节，进行跨页存储。

说实话对char的这个设计我是不太理解的，尽管看了很久，包括官方文档和一些博客🤧，希望懂的同学可以在评论区解惑：

对于长度不固定的字符编码这块，char是不是有点像是一个长度可变的类型了？我们常用的 utf8mb4，占用为 1 ~ 4 字节，那么 char(10) 所占用的空间就是 10 ~ 40 字节，这个变化还是挺大的啊，但是它并没有留足够的空间给它，也没有使用可变长度字段列表去记录char字段的空间占用情况，就很特殊？

开始计算

好了，我们已经知道每一页当中具体存储的东西了，现在我们已经具备计算能力了。

由于页的剩余空间我已经在上面页格式的地方计算过了，每页会剩余 15232 字节可用，下面我们直接计算行。

非叶子节点计算

单个节点计算

索引页就是存索引的节点，也就是非叶子节点。

每一条索引记录当中都包含了当前索引的值 、 一个 6字节 的指针信息 、一个 5 字节的行标头，用来指向下一层数据页的指针。

索引记录当中的指针占用空间我没在官方文档里找到😭，这个 6 字节是我参考其他博文的，他们说源码里写的是6字节，但具体在哪一段源码我也不知道😭。

希望知道的同学可以在评论区解惑。

假设我们的主键id为 bigint 型，也就是8个字节，那索引页中每行数据占用的空间就等于 8+6+5=198 + 6 + 5 = 198+6+5=19 字节。每页可以存 15232÷19≈80115232 \div 19 \approx 80115232÷19≈801 条索引数据。

那算上页目录的话，按每个槽平均6条数据计算的话，至少有 801÷6≈134801 \div 6 \approx 134801÷6≈134 个槽，需要占用 268 字节的空间。

把存数据的空间分一点给槽的话，我算出来大约可以存 787 条索引数据。

如果是主键是 int 型的话，那可以存更多，大约有 993 条索引数据。

前两层非叶子节点计算

在 B+ 树当中，当一个节点索引记录为 NNN 条时，它就会有 NNN 个子节点。由于我们 3 层B+树的前两层都是索引记录，第一层根节点有 NNN 条索引记录，那第二层就会有 NNN 个节点，每个节点数据类型与根节点一致，仍然可以再存 NNN 条记录，第三层的节点个数就会等于 N2N^2N2。

则有：

• 主键为 bigint 的表可以存放 7872=619369787 ^ 2 = 6193697872=619369 个叶子节点

• 主键为 int 的表可以存放 9932=986049993 ^ 2 = 9860499932=986049 个叶子节点

OK计算完毕。

数据条数计算

最少存放记录数

前面我们提到，最大行长度略小于数据库页面的一半，之所以是略小于一半，是由于每个页面还留了点空间给页格式 的其他内容，所以我们可以认为每个页面最少能放两条数据，每条数据略小于8KB。如果某行的数据长度超过这个值，那InnoDB肯定会分一些数据到 溢出页 当中去了，所以我们不考虑。

那每条数据8KB的话，每个叶子节点就只能存放 2 条数据，这样的一张表，在主键为 bigint 的情况下，只能存放 2×619369=12387382 \times 619369 = 12387382×619369=1238738 条数据，也就是一百二十多万条，这个数据量，没想到吧🤣🤣。

较多的存放记录数

假设我们的表是这样的：

-- 这是一张非常普通的课程安排表，除id外，仅包含了课程id和老师id两个字段
-- 且这几个字段均为 int 型（当然实际生产中不会这么设计表，这里只是举例）。

CREATE TABLE `course_schedule` (
  `id` int NOT NULL,
  `teacher_id` int NOT NULL,
  `course_id` int NOT NULL,
  PRIMARY KEY (`id`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

先来分析一下这张表的行数据：无null值列表，无可变长字段列表，需要算上事务ID和指针字段，需要算上行记录头，那么每行数据所占用的空间就是 4+4+4+6+7+5=304 + 4 + 4 + 6 + 7 + 5 = 304+4+4+6+7+5=30 字节，每个叶子节点可以存放 15232÷30≈50715232 \div 30 \approx 50715232÷30≈507 条数据。

算上页目录的槽位所占空间，每个叶子节点可以存放 502 条数据，那么三层B+树可以存放的最大数据量就是 502×986049=494,996,598502 \times 986049 = 494,996,598502×986049=494,996,598，将近5亿条数据！没想到吧🤡😏。

常规表的存放记录数

大部分情况下我们的表字段都不是上面那样的，所以我选择了一场比较常规的表来进行分析，看看能存放多少数据。表情况如下：

CREATE TABLE `blog` (
  `id` bigint unsigned NOT NULL AUTO_INCREMENT COMMENT '博客id',
  `author_id` bigint unsigned NOT NULL COMMENT '作者id',
  `title` varchar(50) CHARACTER SET utf8mb4 NOT NULL COMMENT '标题',
  `description` varchar(250) CHARACTER SET utf8mb4 NOT NULL COMMENT '描述',
  `school_code` bigint unsigned DEFAULT NULL COMMENT '院校代码',
  `cover_image` char(32) DEFAULT NULL COMMENT '封面图',
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `release_time` datetime DEFAULT NULL COMMENT '首次发表时间',
  `modified_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '修改时间',
  `status` tinyint unsigned NOT NULL COMMENT '发表状态',
  `is_delete` tinyint unsigned NOT NULL DEFAULT 0,
  PRIMARY KEY (`id`),
  KEY `author_id` (`author_id`),
  KEY `school_code` (`school_code`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COLLATE=utf8_general_mysql500_ci ROW_FORMAT=DYNAMIC;

这是我的开源项目“校园博客”（GitHub地址：github.com/stick-i/scb…） 中的博客表，用于存放博客的基本数据。

分析一下这张表的行记录：

1. 行记录头信息：肯定得有，占用5字节。

2. 可变长度字段列表：表中 title占用1字节，description占用2字节，共3字节。

3. null值列表：表中仅school_code、cover_image、release_time3个字段可为null，故仅占用1字节。

4. 事务ID和指针字段：两个都得有，占用13字节。

5. 字段内容信息：

   1. id、author_id、school_code 均为bigint型，各占用8字节，共24字节。

   2. create_time、release_time、modified_time 均为datetime类型，各占8字节，共24字节。

   3. status、is_delete 为tinyint类型，各占用1字节，共2字节。

   4. cover_image 为char(32)，字符编码为表默认值utf8，由于该字段实际存的内容仅为英文字母（存url的），结合前面讲的字符编码不同情况下的存储 ，故仅占用32字节。

   5. title、description 分别为varchar(50)、varchar(250)，这两个应该都不会产生溢出页（不太确定），字符编码均为utf8mb4，实际生产中70%以上都是存的中文(3字节)，25%为英文(1字节)，还有5%为4字节的表情😁，则存满的情况下将占用 (50+250)×(0.7×3+0.25×1+0.05×4)=765(50 + 250) \times (0.7 \times 3 + 0.25 \times 1 + 0.05 \times 4 ) = 765(50+250)×(0.7×3+0.25×1+0.05×4)=765 字节。

统计上面的所有分析，共占用 869 字节，则每个叶子节点可以存放 15232÷869≈1715232 \div 869 \approx 1715232÷869≈17 条，算上页目录，仍然能放 17 条。

则三层B+树可以存放的最大数据量就是 17×619369=10,529,27317 \times 619369 = 10,529,27317×619369=10,529,273，约一千万条数据，再次没想到吧👴。

数据计算总结

根据上面三种不同情况下的计算，可以看出，InnoDB三层B+树情况下的数据存储量范围为 一百二十多万条 到 将近5亿条，这个跨度还是非常大的，同时我们也计算了一张博客信息表，可以存储 约一千万条 数据。

所以啊，我们在做项目考虑分表的时候还是得多关注一下表的实际情况，而不是盲目的认为两千万数据都是那个临界点。

面试时如果谈到这块的问题，我想面试官也并不是想知道这个数字到底是多少，而是想看你如何分析这个问题，如何得出这个数字的过程。

如果本文中有任何写的不对的地方，欢迎各位朋友在评论区指正🥰。

写在后面的一些话

这篇文章写了整整两周😭😭（虽然第一周在划水），真的超级干货了，前前后后查了好多资料，也看了好多博文，官方文档有些地方写的确实含糊，我看了好久都没看懂😂😂。

作者：阿杆
来源：juejin.cn/post/7165689453124517896

前几天是 10 月 24 日，有关注股票的同学，相信大家都过了一个非常难忘的程序员节吧。在此，先祝各位朋友们身体健康，股票基金少亏点，最重要的是不被毕业。

抱歉，当了回标题党，不过在做这个决定之前确实纠结了很久，权衡了各种利弊，就我个人而言，不比「3Q 大战」时腾讯做的「艰难的决定」来的轻松。如今距离这个决定过去了快 3 个月，我也还在适应着这个决定带来的变化。

按照工作汇报的习惯，先说结论：

在北漂整整 10 年后，我回老家合肥上班了

做出这个决定的唯一原因：

没有北京户口，积分落户陪跑了三年，目测 45 岁之前落不上

户口搞不定，意味着孩子将来在北京只能考高职，这断然是不能接受的；所以一开始是打算在北京读几年小学后再回老家，我也能多赚点钱，两全其美。

因为我是一个人在北京，如果在北京上小学，就得让我老婆或者让我父母过来。可是我老婆的职业在北京很难就业，我父母年龄大了，北京人生地不熟的，而且那 P 点大的房子，住的也憋屈。而将来一定是要回去读书的，这相当于他们陪着我在北京折腾了。

或者我继续在北京打工赚钱，老婆孩子仍然在老家？之前的 6 年基本都是我老婆在教育和陪伴孩子，我除了逢年过节，每个月回去一到两趟。孩子天生过敏体质，经常要往医院跑，生病时我也帮不上忙，所以时常被抱怨”丧偶式育儿“，我也只能跟渣男一样说些”多喝热水“之类的废话。今年由于那啥，有整整 4 个多月没回家了，孩子都差点”笑问客从何处来“了。。。

5月中旬，积分落户截止，看到贴吧上网友晒出的分数和排名，预计今年的分数线是 105.4，而实际分数线是 105.42，比去年的 100.88 多了 4.54 分。而一般人的年自然增长分数是 4 分，这意味着如果没有特殊加分，永远赶不上分数线的增长。我今年的分数是 90.8，排名 60000 左右，每年 6000 个名额，即使没有人弯道超车，落户也得 10 年后了，孩子都上高一了，不能在初二之前搞到户口，就表示和大学说拜拜了。

经过我的一番仔细的测算，甚至用了杠杆原理和人品守恒定理等复杂公式，最终得到了如下结论：

我这辈子与北京户口无缘了

所以，思前想后，在没有户口的前提下，无论是老婆孩子来北京，还是继续之前的异地，都不是好的解决方案。既然将来孩子一定是在合肥高考，为了减少不必要的折腾，那就只剩唯一的选择了，我回合肥上班，兼顾下家里。

看上去是个挺自然的选择，但是：

我在腾讯是组长，团队 20 余人；回去是普通工程师，工资比腾讯打骨折

不得不说，合肥真的是互联网洼地，就没几个公司招人，更别说薪资匹配和管理岗位了。因此，回合肥意味着我要放弃”高薪“和来之不易的”管理“职位，从头开始，加上合肥这互联网环境，基本是给我的职业生涯判了死刑。所以在 5 月底之前就没考虑过这个选项，甚至 3 月份时还买了个显示器和 1.6m * 0.8m 的大桌子，在北京继续大干一场，而在之前的 10 年里，我都是用笔记本干活的，从未用过外接显示器。

5 月初，脉脉开始频繁传出毕业的事，我所在的部门因为是盈利的，没有毕业的风险。但是营收压力巨大，作为底层的管理者，每天需要处理非常非常多的来自上级、下级以及甲方的繁杂事务，上半年几乎都是凌晨 1 点之后才能睡觉。所以，回去当个普通工程师，每天干完手里的活就跑路，貌似也不是那么不能接受。毕竟自己也当过几年 leader 了，leader 对自己而言也没那么神秘，况且我这还是主动激流勇退，又不是被撸下来的。好吧，也只能这样安慰自己了，中年人，要学会跟自己和解。后面有空时，我分享下作为 leader 和普通工程师所看到的不一样的东西。

在艰难地说服自己接受之后，剩下的就是走各种流程了：

1. 5月底，联系在合肥工作的同学帮忙内推；6月初,通过面试。我就找了一家，其他家估计性价比不行，也不想继续面了
2. 6月底告诉总监，7月中旬告诉团队，陆续约或被约吃散伙饭
3. 7月29日，下午办完离职手续，晚上坐卧铺离开北京
4. 8月1日，到新公司报道

7 月份时，我还干了一件大事，耗时两整天，历经 1200 公里，不惧烈日与暴雨，把我的本田 125 踏板摩托车从北京骑到了合肥，没有拍视频，只能用高德的导航记录作为证据了：

这是导航中断的地方，晚上能见度不行，在山东花了 70 大洋，随便找了个宾馆住下了，第二天早上出发时拍的，发现居然是水泊梁山附近，差点落草为寇：

骑车这两天，路上发生了挺多有意思的事，以后有时间再分享。到家那天，是我的结婚 10 周年纪念日，我没有提前说我要回来，更没说骑着摩托车回来，当我告诉孩子他妈时，问她我是不是很牛逼，得到的答复是：

我觉得你是傻逼

言归正传，在离开北京前几天，我找团队里的同学都聊了聊，对我的选择，非常鲜明的形成了两个派系：

1. 未婚 || 工作 5 年以内的：不理解，为啥放弃管理岗位，未来本可以有更好的发展的，太可惜了，打骨折的降薪更不能接受

2. 已婚 || 工作 5 年以上的：理解，支持，甚至羡慕；既然迟早都要回去，那就早点回，多陪陪家人，年龄大了更不好回；降薪很正常，跟房价也同步，不能既要又要

确实，不同的人生阶段有着不同的想法，我现在是第 2 阶段，需要兼顾家庭和工作了，不能像之前那样把工作当成唯一爱好了。

在家上班的日子挺好的，现在加班不多，就是稍微有点远，单趟得 1 个小时左右。晚上和周末可以陪孩子玩玩，虽然他不喜欢跟我玩🐶。哦，对了，我还有个重要任务 - 做饭和洗碗。真的是悔不当初啊，我就不应该说会做饭的，更不应该把饭做的那么好吃，现在变成我工作以外的最重要的业务了。。。

比较难受的是，现在公司的机器配置一般，M1 的 MBP，16G 内存，512G 硬盘，2K 显示器。除了 CPU 还行，内存和硬盘，都是快 10 年前的配置了，就这还得用上 3 年，想想就头疼，省钱省在刀刃上了，属于是。作为对比，腾讯的机器配置是：

M1 Pro MBP，32G 内存 + 1T SSD + 4K 显示器

客户端开发，再额外配置一台 27寸的 iMac(i9 + 32G内存 + 1T SSD)

由奢入俭难，在习惯了高配置机器后，现在的机器总觉得速度不行，即使很多时候，它和高配机没有区别。作为开发，尤其是客户端开发，AndroidStudio/Xcode 都是内存大户，16G 实在是捉襟见肘，非常影响搬砖效率。公司不允许用自己的电脑，否则我就自己买台 64G 内存的 MBP 干活用了。不过，换个角度，编译时间变长，公司提供了带薪摸鱼的机会，也可以算是个福利🐶

另外，比较失落的就是每个月发工资的日子了，比之前少了太多了，说没感觉是不可能的，还在努力适应中。不过这都是小事，毕竟年底发年终奖时，会更加失落，hhhh😭😭😭😭

先写这么多吧，后面有时间的话，再分享一些有意思的事吧，工作上的或生活上的。

遥想去年码农节时，我还在考虑把房子从昌平换到海淀，好让孩子能有个“海淀学籍”，当时还做了点笔记：

没想到，一年后的我回合肥了，更想不到一年后的腾讯，股价竟然从 500 跌到 206 了(10月28日，200.8 了)。真的是世事难料，大家保重身体，好好活着，多陪陪家人，一起静待春暖花开💪🏻💪🏻

作者：野生的码农

来源：juejin.cn/post/7159837250585362469

之前推送了很多大厂分享，很多同学看完就觉得，大厂输出的理论知识居多，缺乏实践。

那这篇文章，我们将介绍一个大厂的库，这个库能够实打实的帮助大家解决一些问题。

今天的主角：初学者小张，资深研发老羊。

三方库中的 bug

这天 QA 上线前给小张反馈了一个 bug，应用启动就崩溃，小张一点不慌，插入 USB，触发，一看日志，原来是个空指针。

想了想，空指针比较好修复，大不了判空防御一下，于是回答：这个问题交给我，马上修复。

根据堆栈，找到了空指针的元凶。

忽然间，小张愣住了，这个空指针是个三方库在初始化的时候获取用户剪切板出错了。

这可怎么解决呢？

本来以为判个空防御一下完事，这会遇到硬茬了。

毕竟是自己装的逼，含着泪也要修复了，我们模拟下现场。

/**
 * 这是三方库中的调用
 */
public class Tools {
    
    public static String getClipBoardStr(Context context) {
        ClipboardManager clipboardManager = (ClipboardManager) context.getSystemService(Context.CLIPBOARD_SERVICE);
        ClipData primaryClip = clipboardManager.getPrimaryClip();
        // NPE
        ClipData.Item itemAt = primaryClip.getItemAt(0);
        if (itemAt == null) {
            return "";
        }
        CharSequence text = itemAt.getText();
        if (text == null) {
            return "";
        }
        return text.toString();
    }
}

我们写个按钮来触发一下：

果然发生了崩溃，空指针发生在clipboardManager.getPrimaryClip()，当手机上没有过复制内容时，getPrimaryClip返回的就是 null。

马上就要上线了，但是这个问题，也不是修复不了，根据自己的经验，大多数系统服务都可以被 hook，hook 掉 ClipboradManager 的相关方法，保证返回的 getPrimaryClip 的不为 null 即可。

于是看了几个点：

public @Nullable ClipData getPrimaryClip() {
    try {
        return mService.getPrimaryClip(mContext.getOpPackageName(), mContext.getUserId());
    } catch (RemoteException e) {
        throw e.rethrowFromSystemServer();
    }
}

这个 mService 的初始化为：

mService = IClipboard.Stub.asInterface(
                ServiceManager.getServiceOrThrow(Context.CLIPBOARD_SERVICE));

这么看，已经八成可以 hook了，再看下我们自己能构造 ClipData 吗？

public ClipData(CharSequence label, String[] mimeTypes, Item item) {}

恩，hook 的思路基本可行。

小张内心暗喜，多亏是遇到了我呀，还好我实力扎实。

这时候，资深研发老羊过来问了句，马上就要上线了，你这干啥呢？

小张滔滔不绝的描述了一下当前遇到了问题，和自己的解决思路，本以为老羊这次会拍拍自己的肩膀「还好是你遇到了呀」来表示对自己的认可。

老羊开口说道：

getPrimaryClip返回 null 造成的空指针，那你在之前调用一个setPrimaryClip不就行了？

恩？卧槽...看一眼源码：

#ClipboardManager
public void setPrimaryClip(@NonNull ClipData clip) {
    try {
        Preconditions.checkNotNull(clip);
        clip.prepareToLeaveProcess(true);
        mService.setPrimaryClip(clip, mContext.getOpPackageName(), mContext.getUserId());
    } catch (RemoteException e) {
        throw e.rethrowFromSystemServer();
    }
}

还真有这个方法...

那试试吧。

添加了一行：

ClipboardManager clipboardManager = (ClipboardManager) getSystemService(CLIPBOARD_SERVICE);
clipboardManager.setPrimaryClip(new ClipData("bugfix", new String[]{"text/plain"}, new ClipData.Item("")));

果然不在崩溃了。

这时候老羊说了句：

你也想想，假设三方库里面真有个致命的 bug，然后你没找到合适的 hook 点你怎么处理？想好了过来告诉我。

致命 bug，没找到合适的 hook 点？

模拟下代码：

public class Tools {

    public static void evilCode() {
        int a = 1 / 0;
    }

    public static String getClipBoardStr(Context context) {
        evilCode();
        ClipboardManager clipboardManager = (ClipboardManager) context.getSystemService(Context.CLIPBOARD_SERVICE);
        ClipData primaryClip = clipboardManager.getPrimaryClip();
        ClipData.Item itemAt = primaryClip.getItemAt(0);
        if (itemAt == null) {
            return "";
        }
        CharSequence text = itemAt.getText();
        if (text == null) {
            return "";
        }
        return text.toString();
    }


}

假设 getClipBoardStr 内部调用了一行 evilCode，执行到就crash。

一眼望去这个 evilCode 方法，简单是简单，但是在三方库里面怎么解决呢？

小张百思不得其解，忽然灵光一闪：

是不是老羊想考察我的推动能力，让我没事别瞎 hook 人家代码，这种问题当然找三方库那边修复，然后给个新版本咯。

于是跑过去，告诉老羊，我想到了，这种问题，我们应该及时推动三方库那边解决，然后我们升级版本即可。

老羊听了后，恩，确实要找他们，但是如果是上线前遇到，推动肯定是来不及了，就是人家立马给你个新版本，直接升级风险也是比较大的。

然后老羊说道：

我看你对于反射找 hook 点已经比较熟悉了，其实还有一类 hook 更加好用，也更加稳定。

叫做字节码 hook。

怎么说？

我们的代码在打包过程中，会经过如下步骤：

.java -> .class -> dex -> apk

上面那个类的 evil 方法，从 class 文件的角度来看，其实都是字节码。

假设我们在编译过程中，这么做：

.java -> .class -> 拿到 Tools.class，修正里面的方法 evil 方法 -> dex -> apk

这个时机，其实构建过程中也给我们提供了，也就是传说的 Transform 阶段（这里不讨论 AGP 7 之后的变化，还是有对应时机的）。

小张又问，这个时机我知道，Tools.class 文件怎么修改呢？

老羊说，这个你去看看我的博客：

Android 进阶之路：ASM 修改字节码，这样学就对了！

不过话说回来，既然你会遇到这样的痛点，那么别的开发者肯定也会遇到。

这个时候应该怎么想？

小张：肯定有人造了好用的轮子。

老羊：恩，99%的情况，轮子肯定都造好了，剩下 1%，那就是你的机会了。

轻量级 aop 框架 lancet 出现

饿了么，很早的时候就开源了一个框架，叫 lancet。

github.com/eleme/lance…

这个框架可以支持你，在不懂字节码的情况下，也能够完成对对应方法字节码的修改。

代入到我们刚才的思路：

.java -> .class -> lancet 拿到 Tools.class，修正里面的方法 evilCode 方法 -> dex -> apk

小张：怎么使用 lancet 来修改我们的 evilCode 方法呢？

引入框架

在项目的根目录添加：

classpath 'me.ele:lancet-plugin:1.0.6'

在 module 的build.gradle 添加依赖和 apply plugin：

apply plugin: 'me.ele.lancet'

dependencies {
    implementation 'me.ele:lancet-base:1.0.6' // 最好查一下，用最新版本
}

开始使用

然后，我们做一件事情，把Tools 里面的 evilCode方法：

public static void evilCode() {
    int a = 1 / 0;
}

里面的这个代码给去掉，让它变成空方法。

我们编写代码：

package com.imooc.blogdemo.blog04;

import me.ele.lancet.base.annotations.Insert;
import me.ele.lancet.base.annotations.TargetClass;

public class ToolsLancet {

    @TargetClass("com.imooc.blogdemo.blog04.Tools")
    @Insert("evilCode")
    public static void evilCode() {

    }

}

我们编写一个新的方法，保证其是个空方法，这样就完成让原有的 evilCode 中调用没有了。

其中：

• TargetClass 注解：标识你要修改的类名；

• Insert注解：表示你要往 evilCode 这个方法里面注入下面的代码

• 下面的方法声明需要和原方法保持一致，如果有参数，参数也要保持一致（方法名、参数名不需要一致）

然后我们打包，看看背后发生了什么神奇的事情。

在打包完成后，我们反编译，看看 Tools.class

public class Tools {    
   //... 
    public static void evilCode() {
        Tools._lancet.com_imooc_blogdemo_blog04_ToolsLancet_evilCode();
    }

    private static void evilCode$___twin___() {
        int a = 1 / 0;
    }

    private static class _lancet {
        private _lancet() {
        }

        @TargetClass("com.imooc.blogdemo.blog04.Tools")
        @Insert("evilCode")
        static void com_imooc_blogdemo_blog04_ToolsLancet_evilCode() {
        }
    }
}

可以看到，原本的evilCode方法中的校验，被换成了一个生成的方法调用，而这个生成的方法和我们编写的非常类似，并且其为空方法。

而原来的 evilCode 逻辑，放在一个evilCode$___twin___()方法中，可惜这个方法没地方调用。

这样原有的 evilCode 逻辑就变成了一个空方法了。

我们可以大致梳理下原理：

lancet 会将我们注明需要修改的方法调用中转到一个临时方法中，这个临时方法你可以理解为和我们编写的方法逻辑基本保持一致。

然后将该方法的原逻辑也提取到一个新方法中，以备使用。

小张：确实很神奇，那这个原方法我们什么时候会使用呢？

老羊：很多时候，可能原有逻辑只是个概率很低的问题，比如发送请求，只有在超时等情况才发生错误，你不能粗暴的把人家逻辑移除了，你可能更想加个 try-catch 然后给个提示什么的。

这个时候你可以这么改：

package com.imooc.blogdemo.blog04;

import me.ele.lancet.base.Origin;
import me.ele.lancet.base.annotations.Insert;
import me.ele.lancet.base.annotations.TargetClass;

public class ToolsLancet {

    @TargetClass("com.imooc.blogdemo.blog04.Tools")
    @Insert("evilCode")
    public static void evilCode() {
        try {
            Origin.callVoid();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

}

我们再来看下反编译代码：

public class Tools {

    public static void evilCode() {
        Tools._lancet.com_imooc_blogdemo_blog04_ToolsLancet_evilCode();
    }

    private static void evilCode$___twin___() {
        int a = 1 / 0;
    }

    private static class _lancet {
        @TargetClass("com.imooc.blogdemo.blog04.Tools")
        @Insert("evilCode")
        static void com_imooc_blogdemo_blog04_ToolsLancet_evilCode() {
            try {
                Tools.evilCode$___twin___();
            } catch (Exception var1) {
                var1.printStackTrace();
            }

        }
    }
}

看到没，不出所料中转方法内部调用了原有方法，然后外层包了个 try-catch。

是不是很强大，而且相对于运行时反射相关的 hook 更加稳定，其实他就像你写的代码，只不过是直接改的 class。

小张：所以我早上遇到的剪切板崩溃问题，其实也可以利用 lancet 加一个 try-catch。

老羊：是的，挺会举一反三的，当然也从侧面反映出来字节码 hook 的强大之处，几乎不需要找什么 hook 点，只要你有方法，就能干涉。

另外，我给你介绍的都是最基础的 api，你下去好好看看 lancet 的其他用法。

小张：好嘞，又学到了。

新的问题又来了

过了几日，忽然项目又遇到一个问题：

用户未授权读取剪切板之前，不允许有读取剪切板的行为，否则认定为不合规。

小张听到这个任务，大脑快速运转：

这个读取剪切板行为的 API 是：

clipboardManager.getPrimaryClip();

搜索下项目中的调用，然后逐一修改。

先不说能不能搜索完整，这三方库里面肯定有，此外后续新增的代码如何控制呢？

另外之前学习 lancet，可以修改三方库代码，但是我也不能把包含clipboardManager.getPrimaryClip的方法全部列出来，一个个字节码修改？

还是解决不了后续新增，已经能保证全部搜出来呀。

最终心里嘀咕：别让我干，别让我干，八成是个坑。

这时候老羊来了句：这个简单，小张熟悉，他搞就行了。

小张：我...

重新思考一下，反正搜索出来，一一修改是不可能了。

那就从源头上解决：

系统肯定是通过framework，system 进程那边去判断是否读取剪切板的。

那么我们只要把：

clipboardManager.getPrimaryClip
    IClipboard.getPrimaryClip(mContext.getOpPackageName(), mContext.getUserId());

内部的逻辑hook 掉，换掉IClipBoard 的实现，然后切到我们自己的逻辑即可。

懂了，这就是我之前想的系统服务的 hook 而已，难怪老羊安排给我，我给他说过这个。

于是乎...我开启了一顿写模式...

此处代码略。（确实可以，不过非本文主要内容）

正完成了 Android 10.0的测试，准备翻翻各个版本有没有源码修改，好适配适配，老羊走了过来。

说了句：这都两个小时过去了，你还没搞完？

小张：两个小时搞完？你来。

老羊：我让你自己看看 lancet 其他 api你没看？

这个用 lancet 就是送分题你知道吗？看好：

public class ToolsLancet {

    // 模拟用户同意后的状态
    public static boolean isAuth = true;

    @TargetClass("android.content.ClipboardManager")
    @Proxy("getPrimaryClip")
    public ClipData getPrimaryClip() {
        if (isAuth) {
            return (ClipData) Origin.call();
        }
        // 这里也可以 return null,毕竟系统也 return null
        return new ClipData("未授权呢", new String[]{"text/plain"}, new ClipData.Item(""));
    }
}

小张：这个不行呀，android.content.ClipboardManager类是系统的，不是我们写的，在打包阶段没有这个 class。

老羊：我当然知道，你仔细看，这次用的注解和上次有什么不同。

这次用的是:

• @Proxy：意思就是代理，会代理ClipboardManager. getPrimaryClip到我们这个方法中来。

我们反编译看看：

原来的调用：

public static String getClipBoardStr(Context context) {
    ClipboardManager clipboardManager = (ClipboardManager) context.getSystemService(Context.CLIPBOARD_SERVICE);
    ClipData primaryClip = clipboardManager.getPrimaryClip();
    ClipData.Item itemAt = primaryClip.getItemAt(0);
    if (itemAt == null) {
        return "";
    }
    CharSequence text = itemAt.getText();
    if (text == null) {
        return "";
    }
    return text.toString();
}

反编译的调用：

public class Tools {

    public static String getClipBoardStr(Context context) {
        ClipboardManager clipboardManager = (ClipboardManager)context.getSystemService("clipboard");
        ClipData primaryClip = Tools._lancet.com_imooc_blogdemo_blog04_ToolsLancet_getPrimaryClip(clipboardManager);
        Item itemAt = primaryClip.getItemAt(0);
        if (itemAt == null) {
            return "";
        } else {
            CharSequence text = itemAt.getText();
            return text == null ? "" : text.toString();
        }
    }

    private static class _lancet {
    
        @TargetClass("android.content.ClipboardManager")
        @Proxy("getPrimaryClip")
        static ClipData com_imooc_blogdemo_blog04_ToolsLancet_getPrimaryClip(ClipboardManager var0) {
            return ToolsLancet.isAuth ? var0.getPrimaryClip() : new ClipData("未授权呢", new String[]{"text/plain"}, new Item(""));
        }
    }
}

看到没有，clipboardManager.getPrimaryClip()方法变成了Tools._lancet.com_imooc_blogdemo_blog04_ToolsLancet_getPrimaryClip，中转到了我们的hook 实现。

这次明白了吧：

1. lancet 对于我们自己的类中方法，可以使用@Insert 指令；

2. 遇到系统的调用，我们可以针对调用函数使用@Proxy 指令将其中转到中转函数；

好了，lancet 还有一些 api，你再下去好好看看。

完结

终于结束了，大家退出小张和老羊的对话场景。

其实字节码 hook 在 Android 开发过程中更为强大，比我们传统的找 Hook 点（单例，静态变量），然后反射的方式方便太多了，还有个最大的优势就是稳定。

当然lancet hook 有个前提就是要明确知道方法调用，如果你想 hook 一个类的所有调用，那么写起来就有点费劲了，可能并不如动态代理那么方便。

好了，话说回来：

之前有个小伙去面试，被问到：

如何收敛三方库里面线程池的创建？

你有想法了吗？

作者：鸿洋
来源：juejin.cn/post/7034178205728636941

localStorage 是前端本地存储的一种，其容量一般在 5M-10M 左右，用来缓存一些简单的数据基本够用，毕竟定位也不是大数据量的存储。

在某些场景下 localStorage 的容量就会有点捉襟见肘，其实浏览器是有提供大数据量的本地存储的如 IndexedDB 存储数据大小一般在 250M 以上。

弥补了localStorage容量的缺陷，但是使用要比localStorage复杂一些 mdn IndexedDB

不过已经有大佬造了轮子封装了一些调用过程使其使用相对简单，下面我们一起来看一下

localforage

localforage 拥有类似 localStorage API，它能存储多种类型的数据如 Array ArrayBuffer Blob Number Object String，而不仅仅是字符串。

这意味着我们可以直接存 对象、数组类型的数据避免了 JSON.stringify 转换数据的一些问题。

存储其他数据类型时需要转换成上边对应的类型，比如vue3中使用 reactive 定义的数据需要使用toRaw 转换成原始数据进行保存， ref 则直接保存 xxx.value 数据即可。

安装

下载最新版本 或使用 npm bower 进行安装使用。

# 引入下载的 localforage 即可使用
<script src="localforage.js"></script>
<script>console.log('localforage is: ', localforage);</script>

# 通过 npm 安装：
npm install localforage

# 或通过 bower：
bower install localforage

使用

提供了与 localStorage 相同的api，不同的是它是异步的调用返回一个 Promise 对象

localforage.getItem('somekey').then(function(value) {
    // 当离线仓库中的值被载入时，此处代码运行
    console.log(value);
}).catch(function(err) {
    // 当出错时，此处代码运行
    console.log(err);
});

// 回调版本：
localforage.getItem('somekey', function(err, value) {
    // 当离线仓库中的值被载入时，此处代码运行
    console.log(value);
});

提供的方法有

• getItem 根据数据的 key 获取数据 差不多返回 null

• setItem 根据数据的 key 设置数据（存储undefined时getItem获取会返回 null）

• removeItem 根据key删除数据

• length 获取key的数量

• key 根据 key 的索引获取其名

• keys 获取数据仓库中所有的 key。

• iterate 迭代数据仓库中的所有 value/key 键值对。

配置

完整配置可查看文档 这里说个作者觉得有用的

localforage.config({ name: 'My-localStorage' }); 设置仓库的名字，不同的名字代表不同的仓库，当一个应用需要多个本地仓库隔离数据的时候就很有用。

const store = localforage.createInstance({
    name: "nameHere"
});

const otherStore = localforage.createInstance({
    name: "otherName"
});

// 设置某个数据仓库 key 的值不会影响到另一个数据仓库
store.setItem("key", "value");
otherStore.setItem("key", "value2");

同时也支持删除仓库

// 调用时，若不传参，将删除当前实例的 “数据仓库” 。
localforage.dropInstance().then(function() {
  console.log('Dropped the store of the current instance').
});

// 调用时，若参数为一个指定了 name 和 storeName 属性的对象，会删除指定的 “数据仓库”。
localforage.dropInstance({
  name: "otherName",
  storeName: "otherStore"
}).then(function() {
  console.log('Dropped otherStore').
});

// 调用时，若参数为一个仅指定了 name 属性的对象，将删除指定的 “数据库”（及其所有数据仓库）。
localforage.dropInstance({
  name: "otherName"
}).then(function() {
  console.log('Dropped otherName database').
});

idb-keyval

idb-keyval是用IndexedDB实现的一个超级简单的基于 promise 的键值存储。

安装

npm npm install idb-keyval

// 全部引入
import idbKeyval from 'idb-keyval';

idbKeyval.set('hello', 'world')
  .then(() => console.log('It worked!'))
  .catch((err) => console.log('It failed!', err));
  
// 按需引入会摇树
import { get, set } from 'idb-keyval';

set('hello', 'world')
  .then(() => console.log('It worked!'))
  .catch((err) => console.log('It failed!', err));
  
get('hello').then((val) => console.log(val));

浏览器直接引入 <script src="https://cdn.jsdelivr.net/npm/idb-keyval@6/dist/umd.js"></script>

暴露的全局变量是 idbKeyval 直接使用即可。

提供的方法

由于其没有中文的官网，会把例子及自己的理解附上

set 设置数据

值可以是 数字、数组、对象、日期、Blobs等，尽管老Edge不支持null。

键可以是数字、字符串、日期，（IDB也允许这些值的数组，但IE不支持）。

import { set } from 'idb-keyval';

set('hello', 'world')
  .then(() => console.log('It worked!'))
  .catch((err) => console.log('It failed!', err));

setMany 设置多个数据

一个设置多个值，比一个一个的设置更快

import { set, setMany } from 'idb-keyval';

// 不应该:
Promise.all([set(123, 456), set('hello', 'world')])
  .then(() => console.log('It worked!'))
  .catch((err) => console.log('It failed!', err));

// 这样做更快:
setMany([
  [123, 456],
  ['hello', 'world'],
])
  .then(() => console.log('It worked!'))
  .catch((err) => console.log('It failed!', err));

get 获取数据

如果没有键，那么val将返回undefined的。

import { get } from 'idb-keyval';

// logs: "world"
get('hello').then((val) => console.log(val));

getMany 获取多个数据

一次获取多个数据，比一个一个获取数据更快

import { get, getMany } from 'idb-keyval';



// 不应该:

Promise.all([get(123), get('hello')]).then(([firstVal, secondVal]) =>

  console.log(firstVal, secondVal),

);



// 这样做更快:

getMany([123, 'hello']).then(([firstVal, secondVal]) =>

  console.log(firstVal, secondVal),

);

del 删除数据

根据 key 删除数据

import { del } from 'idb-keyval';



del('hello');

delMany 删除多个数据

一次删除多个键，比一个一个删除要快

import { del, delMany } from 'idb-keyval';



// 不应该:

Promise.all([del(123), del('hello')])

  .then(() => console.log('It worked!'))

  .catch((err) => console.log('It failed!', err));



// 这样做更快:

delMany([123, 'hello'])

  .then(() => console.log('It worked!'))

  .catch((err) => console.log('It failed!', err));

update 排队更新数据，防止由于异步导致数据更新问题

因为 get 与 set 都是异步的使用他们来更新数据可能会存在问题如：

// Don't do this:

import { get, set } from 'idb-keyval';



get('counter').then((val) =>

  set('counter', (val || 0) + 1);

);



get('counter').then((val) =>

  set('counter', (val || 0) + 1);

);

上述代码我们期望的是 2 但实际结果是 1，我们可以在第一个回调执行第二次操作。

更好的方法是使用 update 来更新数据

// Instead:

import { update } from 'idb-keyval';



update('counter', (val) => (val || 0) + 1);

update('counter', (val) => (val || 0) + 1);

将自动排队更新，所以第一次更新将计数器设置为1，第二次更新将其设置为2。

clear 清除所有数据

import { clear } from 'idb-keyval';



clear();

entries 返回 [key, value] 形式的数据

import { entries } from 'idb-keyval';



// logs: [[123, 456], ['hello', 'world']]

entries().then((entries) => console.log(entries));

keys 获取所有数据的 key

import { keys } from 'idb-keyval';

// logs: [123, 'hello']
keys().then((keys) => console.log(keys));

values 获取所有数据 value

import { values } from 'idb-keyval';

// logs: [456, 'world']
values().then((values) => console.log(values));

createStore 自定义仓库

文字解释：表 === store === 商店 一个意思

// 自定义数据库名称及表名称
// 创建一个数据库: 数据库名称为 tang_shi， 表名为 table1
const tang_shi_table1 = idbKeyval.createStore('tang_shi', 'table1')

// 向对应仓库添加数据
idbKeyval.set('add', 'table1 的数据', tang_shi_table1)

// 默认创建的仓库名称为 keyval-store 表名为 keyval
idbKeyval.set('add', '默认的数据')

使用 createStore 创建的数据库一个库只会创建一个表即：

// 同一个库有不可以有两个表，custom-store-2 不会创建成功:
const customStore = createStore('custom-db-name', 'custom-store-name');
const customStore2 = createStore('custom-db-name', 'custom-store-2');

// 不同的库 有相同的表名 这是可以的:
const customStore3 = createStore('db3', 'keyval');
const customStore4 = createStore('db4', 'keyval');

promisifyRequest

自己管理定制商店，这个没搞太明白，看文档中说既然都用到这个了不如直接使用idb 这个库

总结

本文介绍了两个 IndexedDB 的库，用来解决 localStorage 存储容量太小的问题

localforage 与 idb-keyval 之间我更喜欢 localforage 因为其与 localStorage 相似的api几乎没有上手成本。

如果需要更加灵活的库可以看一下 dexie.js、PouchDB、idb、JsStore 或者 lovefield 之类的库

感谢观看！

作者：唐诗
来源：juejin.cn/post/7163075131261059086

前言

大家好，我是捡田螺的小男孩。

无论是工作还是面试，我们都会跟ThreadLocal打交道，今天就跟大家聊聊ThreadLocal哈~

1. ThreadLocal是什么?为什么要使用ThreadLocal


2. 一个ThreadLocal的使用案例


3. ThreadLocal的原理


4. 为什么不直接用线程id作为ThreadLocalMap的key


5. 为什么会导致内存泄漏呢？是因为弱引用吗？


6. Key为什么要设计成弱引用呢？强引用不行？


7. InheritableThreadLocal保证父子线程间的共享数据


8. ThreadLocal的应用场景和使用注意点

• github地址，麻烦给个star鼓励一下，感谢感谢


• 公众号：捡田螺的小男孩（欢迎关注，干货多多）

1. ThreadLocal是什么?为什么要使用ThreadLocal？

ThreadLocal是什么?

ThreadLocal，即线程本地变量。如果你创建了一个ThreadLocal变量，那么访问这个变量的每个线程都会有这个变量的一个本地拷贝，多个线程操作这个变量的时候，实际是在操作自己本地内存里面的变量，从而起到线程隔离的作用，避免了并发场景下的线程安全问题。

//创建一个ThreadLocal变量

static ThreadLocal localVariable = new ThreadLocal<>();

为什么要使用ThreadLocal

并发场景下，会存在多个线程同时修改一个共享变量的场景。这就可能会出现线性安全问题。

为了解决线性安全问题，可以用加锁的方式，比如使用synchronized 或者Lock。但是加锁的方式，可能会导致系统变慢。加锁示意图如下：

还有另外一种方案，就是使用空间换时间的方式，即使用ThreadLocal。使用ThreadLocal类访问共享变量时，会在每个线程的本地，都保存一份共享变量的拷贝副本。多线程对共享变量修改时，实际上操作的是这个变量副本，从而保证线性安全。

2. 一个ThreadLocal的使用案例

日常开发中，ThreadLocal经常在日期转换工具类中出现，我们先来看个反例：

/**

 * 日期工具类

 */

public class DateUtil {



    private static final SimpleDateFormat simpleDateFormat =

            new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");



    public static Date parse(String dateString) {

        Date date = null;

        try {

            date = simpleDateFormat.parse(dateString);

        } catch (ParseException e) {

            e.printStackTrace();

        }

        return date;

    }

}

我们在多线程环境跑DateUtil这个工具类：

public static void main(String[] args) {

        ExecutorService executorService = Executors.newFixedThreadPool(10);



        for (int i = 0; i < 10; i++) {

            executorService.execute(()->{

                System.out.println(DateUtil.parse("2022-07-24 16:34:30"));

            });

        }

        executorService.shutdown();

    }

运行后，发现报错了：

如果在DateUtil工具类，加上ThreadLocal，运行则不会有这个问题：

/**

 * 日期工具类

 */

public class DateUtil {



    private static ThreadLocal dateFormatThreadLocal =

            ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"));



    public static Date parse(String dateString) {

        Date date = null;

        try {

            date = dateFormatThreadLocal.get().parse(dateString);

        } catch (ParseException e) {

            e.printStackTrace();

        }

        return date;

    }



    public static void main(String[] args) {

        ExecutorService executorService = Executors.newFixedThreadPool(10);



        for (int i = 0; i < 10; i++) {

            executorService.execute(()->{

                System.out.println(DateUtil.parse("2022-07-24 16:34:30"));

            });

        }

        executorService.shutdown();

    }

}

运行结果：

Sun Jul 24 16:34:30 GMT+08:00 2022

Sun Jul 24 16:34:30 GMT+08:00 2022

Sun Jul 24 16:34:30 GMT+08:00 2022

Sun Jul 24 16:34:30 GMT+08:00 2022

Sun Jul 24 16:34:30 GMT+08:00 2022

Sun Jul 24 16:34:30 GMT+08:00 2022

Sun Jul 24 16:34:30 GMT+08:00 2022

Sun Jul 24 16:34:30 GMT+08:00 2022

Sun Jul 24 16:34:30 GMT+08:00 2022

Sun Jul 24 16:34:30 GMT+08:00 2022

刚刚反例中，为什么会报错呢？这是因为SimpleDateFormat不是线性安全的，它以共享变量出现时，并发多线程场景下即会报错。

为什么加了ThreadLocal就不会有问题呢？并发场景下，ThreadLocal是如何保证的呢？我们接下来看看ThreadLocal的核心原理。

3. ThreadLocal的原理

3.1 ThreadLocal的内存结构图

为了有个宏观的认识，我们先来看下ThreadLocal的内存结构图

从内存结构图，我们可以看到：

• Thread类中，有个ThreadLocal.ThreadLocalMap 的成员变量。


• ThreadLocalMap内部维护了Entry数组，每个Entry代表一个完整的对象，key是ThreadLocal本身，value是ThreadLocal的泛型对象值。

3.2 关键源码分析

对照着几段关键源码来看，更容易理解一点哈~我们回到Thread类源码，可以看到成员变量ThreadLocalMap的初始值是为null

public class Thread implements Runnable {

   //ThreadLocal.ThreadLocalMap是Thread的属性

   ThreadLocal.ThreadLocalMap threadLocals = null;

}

ThreadLocalMap的关键源码如下：

static class ThreadLocalMap {

    

    static class Entry extends WeakReference> {

        /** The value associated with this ThreadLocal. */

        Object value;



        Entry(ThreadLocal k, Object v) {

            super(k);

            value = v;

        }

    }

    //Entry数组

    private Entry[] table;

    

    // ThreadLocalMap的构造器，ThreadLocal作为key

    ThreadLocalMap(ThreadLocal firstKey, Object firstValue) {

        table = new Entry[INITIAL_CAPACITY];

        int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);

        table[i] = new Entry(firstKey, firstValue);

        size = 1;

        setThreshold(INITIAL_CAPACITY);

    }

}

ThreadLocal类中的关键set()方法：

 public void set(T value) {

        Thread t = Thread.currentThread(); //获取当前线程t

        ThreadLocalMap map = getMap(t);  //根据当前线程获取到ThreadLocalMap

        if (map != null)  //如果获取的ThreadLocalMap对象不为空

            map.set(this, value); //K，V设置到ThreadLocalMap中

        else

            createMap(t, value); //创建一个新的ThreadLocalMap

    }

    

     ThreadLocalMap getMap(Thread t) {

       return t.threadLocals; //返回Thread对象的ThreadLocalMap属性

    }



    void createMap(Thread t, T firstValue) { //调用ThreadLocalMap的构造函数

        t.threadLocals = new ThreadLocalMap(this, firstValue); this表示当前类ThreadLocal

    }

ThreadLocal类中的关键get()方法

    public T get() {

        Thread t = Thread.currentThread();//获取当前线程t

        ThreadLocalMap map = getMap(t);//根据当前线程获取到ThreadLocalMap

        if (map != null) { //如果获取的ThreadLocalMap对象不为空

            //由this（即ThreadLoca对象）得到对应的Value，即ThreadLocal的泛型值

            ThreadLocalMap.Entry e = map.getEntry(this);

            if (e != null) {

                @SuppressWarnings("unchecked")

                T result = (T)e.value; 

                return result;

            }

        }

        return setInitialValue(); //初始化threadLocals成员变量的值

    }

    

     private T setInitialValue() {

        T value = initialValue(); //初始化value的值

        Thread t = Thread.currentThread(); 

        ThreadLocalMap map = getMap(t); //以当前线程为key，获取threadLocals成员变量，它是一个ThreadLocalMap

        if (map != null)

            map.set(this, value);  //K，V设置到ThreadLocalMap中

        else

            createMap(t, value); //实例化threadLocals成员变量

        return value;

    }

所以怎么回答ThreadLocal的实现原理？如下，最好是能结合以上结构图一起说明哈~

• Thread线程类有一个类型为ThreadLocal.ThreadLocalMap的实例变量threadLocals，即每个线程都有一个属于自己的ThreadLocalMap。


• ThreadLocalMap内部维护着Entry数组，每个Entry代表一个完整的对象，key是ThreadLocal本身，value是ThreadLocal的泛型值。


• 并发多线程场景下，每个线程Thread，在往ThreadLocal里设置值的时候，都是往自己的ThreadLocalMap里存，读也是以某个ThreadLocal作为引用，在自己的map里找对应的key，从而可以实现了线程隔离。

了解完这几个核心方法后，有些小伙伴可能会有疑惑，ThreadLocalMap为什么要用ThreadLocal作为key呢？直接用线程Id不一样嘛？

4. 为什么不直接用线程id作为ThreadLocalMap的key呢？

举个代码例子，如下：

public class TianLuoThreadLocalTest {



    private static final ThreadLocal threadLocal1 = new ThreadLocal<>();

    private static final ThreadLocal threadLocal2 = new ThreadLocal<>();

 

}

这种场景：一个使用类，有两个共享变量，也就是说用了两个ThreadLocal成员变量的话。如果用线程id作为ThreadLocalMap的key，怎么区分哪个ThreadLocal成员变量呢？因此还是需要使用ThreadLocal作为Key来使用。每个ThreadLocal对象，都可以由threadLocalHashCode属性唯一区分的，每一个ThreadLocal对象都可以由这个对象的名字唯一区分（下面的例子）。看下ThreadLocal代码：

public class ThreadLocal {

  private final int threadLocalHashCode = nextHashCode();

  

  private static int nextHashCode() {

    return nextHashCode.getAndAdd(HASH_INCREMENT);

  }

}

然后我们再来看下一个代码例子：

public class TianLuoThreadLocalTest {



    public static void main(String[] args) {

        Thread t = new Thread(new Runnable(){

            public void run(){

                ThreadLocal threadLocal1 = new ThreadLocal<>();

                threadLocal1.set(new TianLuoDTO("公众号：捡田螺的小男孩"));

                System.out.println(threadLocal1.get());

                ThreadLocal threadLocal2 = new ThreadLocal<>();

                threadLocal2.set(new TianLuoDTO("公众号：程序员田螺"));

                System.out.println(threadLocal2.get());

            }});

        t.start();

    }



}

//运行结果

TianLuoDTO{name='公众号：捡田螺的小男孩'}

TianLuoDTO{name='公众号：程序员田螺'}

再对比下这个图，可能就更清晰一点啦：

5. TreadLocal为什么会导致内存泄漏呢？

5.1 弱引用导致的内存泄漏呢？

我们先来看看TreadLocal的引用示意图哈：

关于ThreadLocal内存泄漏，网上比较流行的说法是这样的：

ThreadLocalMap使用ThreadLocal的弱引用作为key，当ThreadLocal变量被手动设置为null，即一个ThreadLocal没有外部强引用来引用它，当系统GC时，ThreadLocal一定会被回收。这样的话，ThreadLocalMap中就会出现key为null的Entry，就没有办法访问这些key为null的Entry的value，如果当前线程再迟迟不结束的话(比如线程池的核心线程)，这些key为null的Entry的value就会一直存在一条强引用链：Thread变量 -> Thread对象 -> ThreaLocalMap -> Entry -> value -> Object 永远无法回收，造成内存泄漏。

当ThreadLocal变量被手动设置为null后的引用链图：

实际上，ThreadLocalMap的设计中已经考虑到这种情况。所以也加上了一些防护措施：即在ThreadLocal的get,set,remove方法，都会清除线程ThreadLocalMap里所有key为null的value。

源代码中，是有体现的，如ThreadLocalMap的set方法：

  private void set(ThreadLocal key, Object value) {



      Entry[] tab = table;

      int len = tab.length;

      int i = key.threadLocalHashCode & (len-1);



      for (Entry e = tab[i];

            e != null;

            e = tab[i = nextIndex(i, len)]) {

          ThreadLocal k = e.get();



          if (k == key) {

              e.value = value;

              return;

          }



           //如果k等于null,则说明该索引位之前放的key(threadLocal对象)被回收了,这通常是因为外部将threadLocal变量置为null,

           //又因为entry对threadLocal持有的是弱引用,一轮GC过后,对象被回收。

            //这种情况下,既然用户代码都已经将threadLocal置为null,那么也就没打算再通过该对象作为key去取到之前放入threadLocalMap的value, 因此ThreadLocalMap中会直接替换调这种不新鲜的entry。

          if (k == null) {

              replaceStaleEntry(key, value, i);

              return;

          }

        }



        tab[i] = new Entry(key, value);

        int sz = ++size;

        //触发一次Log2(N)复杂度的扫描,目的是清除过期Entry  

        if (!cleanSomeSlots(i, sz) && sz >= threshold)

          rehash();

    }

如ThreadLocal的get方法：

  public T get() {

    Thread t = Thread.currentThread();

    ThreadLocalMap map = getMap(t);

    if (map != null) {

        //去ThreadLocalMap获取Entry，方法里面有key==null的清除逻辑

        ThreadLocalMap.Entry e = map.getEntry(this);

        if (e != null) {

            @SuppressWarnings("unchecked")

            T result = (T)e.value;

            return result;

        }

    }

    return setInitialValue();

}



private Entry getEntry(ThreadLocal key) {

        int i = key.threadLocalHashCode & (table.length - 1);

        Entry e = table[i];

        if (e != null && e.get() == key)

             return e;

        else

          //里面有key==null的清除逻辑

          return getEntryAfterMiss(key, i, e);

    }

        

private Entry getEntryAfterMiss(ThreadLocal key, int i, Entry e) {

        Entry[] tab = table;

        int len = tab.length;



        while (e != null) {

            ThreadLocal k = e.get();

            if (k == key)

                return e;

            // Entry的key为null,则表明没有外部引用,且被GC回收,是一个过期Entry

            if (k == null)

                expungeStaleEntry(i); //删除过期的Entry

            else

                i = nextIndex(i, len);

            e = tab[i];

        }

        return null;

    }