最近公司里事儿比较多，项目也比较杂，但是因为公司的项目主要是聚焦OA方面，很多东西可以复用。

比方说：表单、表格、搜索栏等等，这部分现阶段大部分都是各写各的，每个项目因为主要的开发不同，各自维护自己的一份。

但是领导现在觉得还是维护一套组件库来的比较方便，一来是减少重复工作量，提升开发效率，二来是方便新人加入团队以后尽量与老成员开发风格保持一致。

另外还有一个原因是项目内现在有的用AntDesign，有的用ElmentPlus，这些库的样式和UI设计出来的风格不搭，改起来也非常麻烦。

我听见这个提议以后后背冷汗都下来了。

我再跟大家强调一遍，不要封装组件库！

咱们说说为什么：

抬高开发成本

大部分人都感觉封装组件库是降低了开发成本，但实际上大部分项目并非如此，封装组件库大部分时候都是抬高了开发成本。

项目不同，面对的客户不同，需求也就不同，所以无论是客户方的需求还是UI设计稿都存在一定的差别，有些时候差距很大。

针对项目单独进行开发虽然在表面上看起来是浪费了人力资源，重复了很多工作，但是在后期开发和维护过程中会节省非常多的时间。

这部分都是成本。很多时候组件的开发并不是面对产品或者团队的，而是面向项目和客户的。

这也就导致了组件的开发会存在极大的不确定性，一方面是需求的不确定，另一方面是组件灵活度的不确定。

很多时候开发出来的组件库会衍生出N多个版本，切出N多个分支，最后在各个项目中引用，逐渐变成一个臃肿的垃圾代码集合体。

我不相信有人会在自己的项目上改完以后，还把修改的部分根据他人的反馈再进行调整，最后合并到 master 分支上去。

我从未见过有这个操作的兄弟。

技术达不到封装水平

团队内部技术不在一个水平线上，事实上也不可能在一个水平线上。

有些人的技术好，封装出来的组件确实很契合大多数的业务场景，有些人技术稍逊，封装出来的组件就不一定能契合项目。

但是如果你用他人封装的组件，牵扯到定制化需求的时候势必会改造，这时候改造就有可能会影响其他项目。

尤其一种情况，老项目升级，这是组件库最容易出问题的时候。可能上个版本封版的组件库在老项目运行的非常完美，但是需要升级的项目引用新的组件库的时候就会出现很多问题。

大部分程序员其实都达不到封装组件库的水准。

如果想要试一试可以参考ElmentUI老版本代码，自己封装一下Select、Input、Button这几个组件，看看和这些久经考验的开源组件库编码程序员还差多少。

技术负债严重

承接上一个问题，不是团队内每个人的水平都一样，并且每个人的编码风格也都是不一样的。(Ts最大的作用点)

可能组件库建立初期会节省非常多的重复工作，毕竟拿来就用，而且本身就是封装好的，简直可以为自己鼓掌了。

照着镜子问这是哪个天才编写的组件库，简直不要太棒了。

但是随着时间的推移，你会发现这个组件库越来越难用，需要考虑的方面越来越多，受影响的模块越来越多，你会变得越来越不敢动其中的代码。

项目越来越多，组件库中的分支和版本越来越多，团队中的人有些已经离开，有些人刚来，这时候技术负债就已经形成了。

更不要说大部分人没有写技术文档的习惯，甚至是连写注释的习惯都没有，功能全靠看代码和猜，技术上的负债越来越严重，这个阶段组件库离崩塌就已经不远了。

新项目在立项之初你就会本能的排斥使用组件库，但是对于老项目呢？改是不可能改动的，但是不维护Bug又挂在这儿。

那你到底是选择代码能跑，还是选择...

对个人发展不利

有些兄弟觉得能封装组件库，让自己的代码在这个团队，这个公司永远的流传下去，简直是跟青史留名差不多了。以后谁用到这个组件都会看到author后面写着我的名字。

但事实并非如此！

封装出的组件库大部分情况下会让你"青💩留名"，因为后面的每个人用这个组件都会骂，这是哪个zz封装的组件，为啥这么写，这里不应该这么写嘛？

如果你一直呆在这个公司，由你一手搭建的这个组件库将伴随你在这个公司的整个职业生涯。

一时造轮子，一辈子维护轮子！

只要任何人用到你这个组件库，遇到了问题一定会来找你。不管你现在到底有没有在负责这个组件库！

这种通用性的组件库不可能没有问题，但是一旦有了问题找到你，你或者是解决不了，又或者是解决的不及时，都将或多或少的影响你的同事对你的评价。

当所有人都对你封装的这个组件库不满意，并且在开组会的时候提出来因为xx封装的组件库不好使，导致了项目延期，时间一长你的领导会对你有好印象？

结语

希望兄弟们还是要明白，对于一个职场人来说，挣钱最重要，能升上去最重要。其他的所有都是细枝末节，不必太在意。

对于客户和老板而言，能快速交付，把钱挣到手最重要，其他也都是无所谓的小事。

对于咱们自己来说，喜欢折腾是程序员的特质，但是要分清形势。

在 JavaScript 开发中，遵循良好的编程规范对于构建高效、可维护的代码至关重要。它不仅能提升代码的可读性，让团队成员之间更容易理解和协作，还能减少错误的发生，提高开发效率。本文将详细介绍 JavaScript 编程中的一些重要规范。

一、命名规范

变量和函数命名

采用小驼峰命名法，第一个单词首字母小写，后续单词首字母大写。例如firstName用于表示名字变量，getUserName函数用于获取用户名。这种命名方式能够清晰地区分变量和函数，并且让名称具有语义化，便于理解其用途。避免使用单字母或无意义的命名，如a、b等，除非在特定的循环等场景下有约定俗成的用法。

常量命名

常量通常使用全大写字母，单词之间用下划线分隔，比如MAX_COUNT表示最大计数，API_URL表示 API 的链接地址。这样的命名方式能够直观地让开发者知道该变量是一个常量，其值在程序运行过程中不会改变。

二、语法规范

使用严格模式

在脚本或函数的开头添加'use strict';开启严格模式。严格模式下，JavaScript 会进行更严格的语法检查，比如禁止使用未声明的变量，防止意外创建全局变量等常见错误。它有助于开发者养成良好的编程习惯，提高代码的质量和稳定性。

// 严格模式

function strictWithExample() {

    'use strict';

    var obj = { x: 1 };

    // 抛出 SyntaxError

    with (obj) {

        console.log(x);

    }

}

strictWithExample();

语句结束加分号

尽管 JavaScript 在某些情况下可以省略分号，但为了避免潜在的错误和代码歧义，强烈建议在每条语句结束后都加上分号。

例如let num = 5和let num = 5;，前者在一些复杂的代码结构中可能会因为自动分号插入机制而出现意想不到的问题，而后者则明确地表示了语句的结束。

let num = 5

console.log(num)

[1, 2, 3].forEach(function (element) {

    console.log(element);

});

在上述代码中，let num = 5 后面没有分号，由于 [ 是 JavaScript 中的数组字面量符号，同时也可以用于数组的索引访问操作（例如 arr[0]），所以引擎会认为你可能想要对 num 进行某种与数组相关的操作，比如 num[1, 2, 3]（虽然这在语法上是错误的，因为 num 是一个数字，不是数组）。

代码缩进

统一使用 2 个或 4 个空格进行缩进，这能让代码的层次结构一目了然。比如在嵌套的if - else语句、循环语句等结构中，合理的缩进能清晰地展示代码的逻辑关系，使代码更易于阅读和维护。

代码块使用大括号

即使代码块中只有一条语句，也建议使用大括号括起来。例如：

if (condition) {

    doSomething();

}

这样在后续需要添加更多语句到代码块中时，能避免因遗漏大括号而导致的语法错误。

三、比较操作规范

尽量使用===和!==进行比较操作，避免使用==和!=。因为==和!=在比较时会进行类型转换，这可能会带来意外结果。例如'5' == 5会返回true，而'5' === 5会返回false，在实际开发中，明确知道数据类型并使用全等操作符能减少错误的发生。

四、代码结构规范

避免全局变量污染

在 JavaScript 开发中，尤其是构建大型项目时，全局变量带来的问题不容小觑。全局变量如同在公共空间随意摆放的物品，极易引发混乱。在一个复杂项目中，可能有多个开发人员同时工作，不同模块的代码相互交织。如果每个模块都随意创建全局变量，很容易出现命名冲突。

• 例如，一个模块定义了全局变量count用于记录某个操作的次数，另一个模块可能也需要使用count变量来记录其他信息，这就会导致变量值被意外覆盖，引发难以排查的错误。

同时，在大型项目中，代码的维护和调试本身就具有挑战性。全局变量的存在会使问题变得更加棘手。因为全局变量在整个程序的生命周期内都存在，其值可能在程序的任何地方被修改。当出现错误时，开发人员很难确定是哪个部分的代码对全局变量进行了不恰当的修改，增加了调试的难度和时间成本。

模块化

为了解决这些问题，模块化是一种非常有效的手段。通过将相关的功能代码封装在一个模块中，每个模块都有自己独立的作用域。在 JavaScript 中，ES6 引入了模块系统，使用export和import关键字来管理模块的导出和导入。例如，有一个处理用户数据的模块userModule.js：

// userModule.js

const userData = {

    name: '',

    age: 0

};



function setUserName(name) {

    userData.name = name;

}



function getUserName() {

    return userData.name;

}



export { setUserName, getUserName };

在这个模块中，userData和setUserName、getUserName函数都在模块内部作用域中，外部无法直接访问userData。只有通过导出的setUserName和getUserName函数，其他模块才能间接操作userData。在其他模块中使用时，可以这样导入：

// main.js

import { setUserName, getUserName } from './userModule.js';



setUserName('John');

console.log(getUserName()); 

这样就有效地避免了全局变量的使用，降低了命名冲突的风险，同时也使得代码的结构更加清晰，易于维护和调试。

立即执行函数表达式（IIFE）

另一种方式是使用立即执行函数表达式（IIFE）。在 JavaScript 中，通过将函数定义包裹在括号中，并紧接着在后面加上括号进行调用，便形成了一个 IIFE。IIFE 能够创建一个独立的函数作用域，在该作用域内定义的变量和函数均为私有。这就确保了函数内部的变量和函数不会被外部随意访问和修改 。例如：

const app = (function () {

    let privateVariable = 10;



    function privateFunction() {

        console.log('This is a private function.');

    }



    return {

        publicFunction: function () {

            privateFunction();

            console.log('The value of private variable is:', privateVariable);

        }

    };

})();



app.publicFunction(); 

在上述代码中，

• (function () {... })()：在包裹匿名函数的括号后面再添加一对括号()，这对括号用于立即调用前面定义的匿名函数。当 JavaScript 引擎执行到这部分代码时，就会立即调用这个匿名函数，所以称为 “立即执行函数”。


• privateVariable和privateFunction都在 IIFE 内部的私有作用域中，因此外部无法直接访问它们。通过返回一个包含publicFunction的对象，向外暴露了一个公共接口，这样一来既实现了功能，又避免了全局变量污染。

合理使用注释

在关键代码逻辑处添加注释，解释代码的功能、用途、算法思路等。注释要简洁准确，避免过度注释。

• 例如在一个复杂的算法函数前，可以注释说明该算法的作用、输入参数和返回值的含义，方便其他开发者理解代码。


• 但不要在过于简单的代码上添加冗余注释，如let num = 1; // 定义一个数字变量，这样的注释对理解代码没有实质性帮助。

五、注释规范

注释分为单行注释和多行注释。单行注释使用//，用于对某一行代码进行简单解释。多行注释使用/* */，适合对一段代码块进行详细说明。在写注释时，要确保注释与代码同步更新，避免代码修改后注释不再准确的情况。

六、异步编程规范

随着 JavaScript 在前端和后端开发中的广泛应用，异步编程变得越来越重要。使用async/await语法可以让异步代码看起来更像同步代码，提高代码的可读性。例如：

async function getData() {

    try {

        let response = await fetch('https://example.com/api');

        let data = await response.json();

        return data;

    } catch (error) {

        console.error('获取数据失败', error);

    }

}

在处理多个异步操作时，要注意合理控制并发数量，避免因过多并发请求导致性能问题。

七、代码格式化规范

使用代码格式化工具，如 Prettier、ESLint 等，能够自动按照设定的规则对代码进行格式化。它可以统一代码风格，包括缩进、空格、换行等，使团队成员的代码风格保持一致，减少因风格差异带来的冲突和阅读障碍。

八、代码复用

尽量编写可复用的代码，通过函数封装、模块封装等方式，将重复使用的代码逻辑提取出来。

• 例如，在多个地方需要对数据进行格式化处理，可以编写一个通用的数据格式化函数，在需要的地方调用，这样不仅能减少代码量，还方便维护和修改。

九、错误处理

在代码中要合理处理错误，使用try - catch块捕获可能出现的异常。对于异步操作，也要通过try - catch或者.catch方法来处理错误。

• 例如在网络请求失败时，要及时向用户反馈错误信息，而不是让程序崩溃。同时，可以自定义错误类型，以便在不同的业务场景下进行更精准的错误处理。

遵循这些 JavaScript 编程规范，能够帮助开发者写出更整洁、高效、易于维护的代码。在实际开发中，团队可以根据项目需求进一步细化和完善这些规范，以提升整个项目的质量。

大家好，我是程序员鱼皮。我发现很多程序员都不打日志，有的是 不想 打、有的是 意识不到 要打、还有的是 真不会 打日志啊！

前段时间的模拟面试中，我问了几位应届的 Java 开发同学 “你在项目中是怎么打日志的”，得到的答案竟然是 “支支吾吾”、“阿巴阿巴”，更有甚者，竟然表示：直接用 System.out.println() 打印一下吧。。。

要知道，日志是我们系统出现错误时，最快速有效的定位工具，没有日志给出的错误信息，遇到报错你就会一脸懵逼；而且日志还可以用来记录业务信息，比如记录用户执行的每个操作，不仅可以用于分析改进系统，同时在遇到非法操作时，也能很快找到凶手。

因此，对于程序员来说，日志记录是重要的基本功。但很多同学并没有系统学习过日志操作、缺乏经验，所以我写下这篇文章，分享自己在开发项目中记录日志的方法和最佳实践，希望对大家有帮助~

一、日志记录的方法

日志框架选型

有很多 Java 的日志框架和工具库，可以帮我们用一行代码快速完成日志记录。

在学习日志记录之前，很多同学应该是通过 System.out.println 输出信息来调试程序的，简单方便。

但是，System.out.println 存在很严重的问题！

首先，System.out.println 是一个同步方法，每次调用都会导致 I/O 操作，比较耗时，频繁使用甚至会严重影响应用程序的性能，所以不建议在生产环境使用。此外，它只能输出简单的信息到标准控制台，无法灵活设置日志级别、格式、输出位置等。

所以我们一般会选择专业的 Java 日志框架或工具库，比如经典的 Apache Log4j 和它的升级版 Log4j 2，还有 Spring Boot 默认集成的 Logback 库。不仅可以帮我们用一行代码更快地完成日志记录，还能灵活调整格式、设置日志级别、将日志写入到文件中、压缩日志等。

可能还有同学听说过 SLF4J（Simple Logging Facade for Java），看英文名就知道了，这玩意并不是一个具体的日志实现，而是为各种日志框架提供简单统一接口的日志门面（抽象层）。

啥是门面？

举个例子，现在我们要记录日志了，先联系到前台接待人员 SLF4J，它说必须要让我们选择日志的级别（debug / info / warn / error），然后要提供日志的内容。确认之后，SLF4J 自己不干活，屁颠屁颠儿地去找具体的日志实现框架，比如 Logback，然后由 Logback 进行日志写入。

这样做有什么好处呢？无论我们选择哪套日志框架、或者后期要切换日志框架，调用的方法始终是相同的，不用再去更改日志调用代码，比如将 log.info 改为 log.printInfo。

既然 SLF4J 只是玩抽象，那么 Log4j、Log4j 2 和 Logback 应该选择哪一个呢？

值得一提的是，SLF4J、Log4j 和 Logback 竟然都是同一个作者（俄罗斯程序员 Ceki Gülcü）。

首先，Log4j 已经停止维护，直接排除。Log4j 2 和 Logback 基本都能满足功能需求，那么就看性能、稳定性和易用性。

• 从性能来说，Log4j 2 和 Logback 虽然都支持异步日志，但是 Log4j 基于 LMAX Disruptor 高性能异步处理库实现，性能更高。


• 从稳定性来说，虽然这些日志库都被曝出过漏洞，但 Log4j 2 的漏洞更为致命，姑且算是 Logback 得一分。


• 从易用性来说，二者差不多，但 Logback 是 SLF4J 的原生实现、Log4j2 需要额外使用 SLF4J 绑定器实现。

再加上 Spring Boot 默认集成了 Logback，如果没有特殊的性能需求，我会更推荐初学者选择 Logback，都不用引入额外的库了~

使用日志框架

日志框架的使用非常简单，一般需要先获取到 Logger 日志对象，然后调用 logger.xxx（比如 logger.info）就能输出日志了。

最传统的方法就是通过 LoggerFactory 手动获取 Logger，示例代码如下：

import org.slf4j.Logger;

import org.slf4j.LoggerFactory;

​

public class MyService {

   private static final Logger logger = LoggerFactory.getLogger(MyService.class);

​

   public void doSomething() {

       logger.info("执行了一些操作");

  }

}

上述代码中，我们通过调用日志工厂并传入当前类，创建了一个 logger。但由于每个类的类名都不同，我们又经常复制这行代码到不同的类中，就很容易忘记修改类名。

所以我们可以使用 this.getClass 动态获取当前类的实例，来创建 Logger 对象：

public class MyService {

   private final Logger logger = LoggerFactory.getLogger(this.getClass());

​

   public void doSomething() {

       logger.info("执行了一些操作");

  }

}

给每个类都复制一遍这行代码，就能愉快地打日志了。

但我觉得这样做还是有点麻烦，我连复制粘贴都懒得做，怎么办？

还有更简单的方式，使用 Lombok 工具库提供的 @Slf4j 注解，可以自动为当前类生成一个名为 log 的 SLF4J Logger 对象，简化了 Logger 的定义过程。示例代码如下：

import lombok.extern.slf4j.Slf4j;

​

@Slf4j

public class MyService {

   public void doSomething() {

       log.info("执行了一些操作");

  }

}

这也是我比较推荐的方式，效率杠杠的。

此外，你可以通过修改日志配置文件（比如 logback.xml 或 logback-spring.xml）来设置日志输出的格式、级别、输出路径等。日志配置文件比较复杂，不建议大家去记忆语法，随用随查即可。

二、日志记录的最佳实践

学习完日志记录的方法后，再分享一些我个人记录日志的经验。内容较多，大家可以先了解一下，实际开发中按需运用。

1、合理选择日志级别

日志级别的作用是标识日志的重要程度，常见的级别有：

• TRACE：最细粒度的信息，通常只在开发过程中使用，用于跟踪程序的执行路径。


• DEBUG：调试信息，记录程序运行时的内部状态和变量值。


• INFO：一般信息，记录系统的关键运行状态和业务流程。


• WARN：警告信息，表示可能存在潜在问题，但系统仍可继续运行。


• ERROR：错误信息，表示出现了影响系统功能的问题，需要及时处理。


• FATAL：致命错误，表示系统可能无法继续运行，需要立即关注。

其中，用的最多的当属 DEBUG、INFO、WARN 和 ERROR 了。

建议在开发环境使用低级别日志（比如 DEBUG），以获取详细的信息；生产环境使用高级别日志（比如 INFO 或 WARN），减少日志量，降低性能开销的同时，防止重要信息被无用日志淹没。

注意一点，日志级别未必是一成不变的，假如有一天你的程序出错了，但是看日志找不到任何有效信息，可能就需要降低下日志输出级别了。

2、正确记录日志信息

当要输出的日志内容中存在变量时，建议使用参数化日志，也就是在日志信息中使用占位符（比如 {}），由日志框架在运行时替换为实际参数值。

比如输出一行用户登录日志：

// 不推荐

logger.debug("用户ID：" + userId + " 登录成功。");

​

// 推荐

logger.debug("用户ID：{} 登录成功。", userId);

这样做不仅让日志清晰易读；而且在日志级别低于当前记录级别时，不会执行字符串拼接，从而避免了字符串拼接带来的性能开销、以及潜在的 NullPointerException 问题。所以建议在所有日志记录中，使用参数化的方式替代字符串拼接。

此外，在输出异常信息时，建议同时记录上下文信息、以及完整的异常堆栈信息，便于排查问题：

try {

   // 业务逻辑

} catch (Exception e) {

logger.error("处理用户ID：{} 时发生异常：", userId, e);

}

3、控制日志输出量

过多的日志不仅会占用更多的磁盘空间，还会增加系统的 I/O 负担，影响系统性能。

因此，除了根据环境设置合适的日志级别外，还要尽量避免在循环中输出日志。

可以添加条件来控制，比如在批量处理时，每处理 1000 条数据时才记录一次：

if (index % 1000 == 0) {

   logger.info("已处理 {} 条记录", index);

}

或者在循环中利用 StringBuilder 进行字符串拼接，循环结束后统一输出：

StringBuilder logBuilder = new StringBuilder("处理结果：");

for (Item item : items) {

   try {

       processItem(item);

       logBuilder.append(String.format("成功[ID=%s], ", item.getId()));

  } catch (Exception e) {

       logBuilder.append(String.format("失败[ID=%s, 原因=%s], ", item.getId(), e.getMessage()));

  }

}

logger.info(logBuilder.toString());

如果参数的计算开销较大，且当前日志级别不需要输出，应该在记录前进行级别检查，从而避免多余的参数计算：

if (logger.isDebugEnabled()) {

   logger.debug("复杂对象信息：{}", expensiveToComputeObject());

}

此外，还可以通过更改日志配置文件整体过滤掉特定级别的日志，来防止日志刷屏：

<!-- Logback 示例 -->

<appender name="LIMITED" class="ch.qos.logback.classic.AsyncAppender">

<!-- 只允许 INFO 级别及以上的日志通过 -->

   <filter class="ch.qos.logback.classic.filter.ThresholdFilter">

       <level>INFO</level>

   </filter>

   <!-- 配置其他属性 -->

</appender>

4、把控时机和内容

很多开发者（尤其是线上经验不丰富的开发者）并没有养成记录日志的习惯，觉得记录日志不重要，等到出了问题无法排查的时候才追悔莫及。

一般情况下，需要在系统的关键流程和重要业务节点记录日志，比如用户登录、订单处理、支付等都是关键业务，建议多记录日志。

对于重要的方法，建议在入口和出口记录重要的参数和返回值，便于快速还原现场、复现问题。

对于调用链较长的操作，确保在每个环节都有日志，以便追踪到问题所在的环节。

如果你不想区分上面这些情况，我的建议是尽量在前期多记录一些日志，后面再慢慢移除掉不需要的日志。比如可以利用 AOP 切面编程在每个业务方法执行前输出执行信息：

@Aspect

@Component

public class LoggingAspect {

​

   @Before("execution(* com.example.service..*(..))")

   public void logBeforeMethod(JoinPoint joinPoint) {

       Logger logger = LoggerFactory.getLogger(joinPoint.getTarget().getClass());

       logger.info("方法 {} 开始执行", joinPoint.getSignature().getName());

  }

}

利用 AOP，还可以自动打印每个 Controller 接口的请求参数和返回值，这样就不会错过任何一次调用信息了。

不过这样做也有一个很重要的点，注意不要在日志中记录了敏感信息，比如用户密码。万一你的日志不小心泄露出去，就相当于泄露了大量用户的信息。

5、日志管理

随着日志文件的持续增长，会导致磁盘空间耗尽，影响系统正常运行，所以我们需要一些策略来对日志进行管理。

首先是设置日志的滚动策略，可以根据文件大小或日期，自动对日志文件进行切分。比如按文件大小滚动：

<!-- 按大小滚动 -->

<rollingPolicy class="ch.qos.logback.core.rolling.SizeBasedRollingPolicy">

   <maxFileSize>10MB</maxFileSize>

</rollingPolicy>

如果日志文件大小达到 10MB，Logback 会将当前日志文件重命名为 app.log.1 或其他命名模式（具体由文件名模式决定），然后创建新的 app.log 文件继续写入日志。

还有按照时间日期滚动：

<!-- 按时间滚动 -->

<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">

   <fileNamePattern>logs/app-%d{yyyy-MM-dd}.log</fileNamePattern>

</rollingPolicy>

上述配置表示每天创建一个新的日志文件，%d{yyyy-MM-dd} 表示按照日期命名日志文件，例如 app-2024-11-21.log。

还可以通过 maxHistory 属性，限制保留的历史日志文件数量或天数：

<maxHistory>30</maxHistory>

这样一来，我们就可以按照天数查看指定的日志，单个日志文件也不会很大，提高了日志检索效率。

对于用户较多的企业级项目，日志的增长是飞快的，因此建议开启日志压缩功能，节省磁盘空间。

<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">

   <fileNamePattern>logs/app-%d{yyyy-MM-dd}.log.gz</fileNamePattern>

</rollingPolicy>

上述配置表示：每天生成一个新的日志文件，旧的日志文件会被压缩存储。

除了配置日志切分和压缩外，我们还需要定期审查日志，查看日志的有效性和空间占用情况，从日志中发现系统的问题、清理无用的日志信息等。

如果你想偷懒，也可以写个自动化清理脚本，定期清理过期的日志文件，释放磁盘空间。比如：

# 每月清理一次超过 90 天的日志文件

find /var/log/myapp/ -type f -mtime +90 -exec rm {} ;

6、统一日志格式

统一的日志格式有助于日志的解析、搜索和分析，特别是在分布式系统中。

我举个例子大家就能感受到这么做的重要性了。

统一的日志格式：

2024-11-21 14:30:15.123 [main] INFO com.example.service.UserService - 用户ID：12345 登录成功

2024-11-21 14:30:16.789 [main] ERROR com.example.service.UserService - 用户ID：12345 登录失败，原因：密码错误

2024-11-21 14:30:17.456 [main] DEBUG com.example.dao.UserDao - 执行SQL：[SELECT * FROM users WHERE id=12345]

2024-11-21 14:30:18.654 [main] WARN com.example.config.AppConfig - 配置项 `timeout` 使用默认值：3000ms

2024-11-21 14:30:19.001 [main] INFO com.example.Main - 应用启动成功，耗时：2.34秒

这段日志整齐清晰，支持按照时间、线程、级别、类名和内容搜索。

不统一的日志格式：

2024/11/21 14:30 登录成功 用户ID: 12345

2024-11-21 14:30:16 错误 用户12345登录失败！密码不对

DEBUG 执行SQL SELECT * FROM users WHERE id=12345

Timeout = default

应用启动成功

emm，看到这种日志我直接原地爆炸！

建议每个项目都要明确约定和配置一套日志输出规范，确保日志中包含时间戳、日志级别、线程、类名、方法名、消息等关键信息。

<!-- 控制台日志输出 -->

<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">

   <encoder>

       <!-- 日志格式 -->

       <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>

   </encoder>

</appender>

也可以直接使用标准化格式，比如 JSON，确保所有日志遵循相同的结构，便于后续对日志进行分析处理：

<encoder class="net.logstash.logback.encoder.LoggingEventCompositeJsonEncoder">

   <!-- 配置 JSON 编码器 -->

</encoder>

此外，你还可以通过 MDC（Mapped Diagnostic Context）给日志添加额外的上下文信息，比如用户 ID、请求 ID 等，方便追踪。在 Java 代码中，可以为 MDC 变量设置值：

MDC.put("requestId", "666");

MDC.put("userId", "yupi");

logger.info("用户请求处理完成");

MDC.clear();

对应的日志配置如下：

<!-- 文件日志配置 -->

<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">

   <encoder>

       <!-- 包含 MDC 信息 -->

       <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - [%X{requestId}] [%X{userId}] %msg%n</pattern>

   </encoder>

</appender>

这样，每个请求、每个用户的操作一目了然。

7、使用异步日志

对于追求性能的操作，可以使用异步日志，将日志的写入操作放在单独的线程中，减少对主线程的阻塞，从而提升系统性能。

除了自己开线程去执行 log 操作之外，还可以直接修改配置来开启 Logback 的异步日志功能：

<!-- 异步 Appender -->

<appender name="ASYNC" class="ch.qos.logback.classic.AsyncAppender">

   <queueSize>500</queueSize> <!-- 队列大小 -->

   <discardingThreshold>0</discardingThreshold> <!-- 丢弃阈值，0 表示不丢弃 -->

   <neverBlock>true</neverBlock> <!-- 队列满时是否阻塞主线程，true 表示不阻塞 -->

   <appender-ref ref="CONSOLE" /> <!-- 生效的日志目标 -->

   <appender-ref ref="FILE" />

</appender>

上述配置的关键是配置缓冲队列，要设置合适的队列大小和丢弃策略，防止日志积压或丢失。

8、集成日志收集系统

在比较成熟的公司中，我们可能会使用更专业的日志管理和分析系统，比如 ELK（Elasticsearch、Logstash、Kibana）。不仅不用每次都登录到服务器上查看日志文件，还可以更灵活地搜索日志。

但是搭建和运维 ELK 的成本还是比较大的，对于小团队，我的建议是不要急着搞这一套。

OK，就分享到这里，洋洋洒洒 4000 多字，希望这篇文章能帮助大家意识到日志记录的重要性，并养成良好的日志记录习惯。学会的话给鱼皮点个赞吧~

日志不是写给机器看的，是写给未来的你和你的队友看的！

更多

💻 编程学习交流：编程导航

📃 简历快速制作：老鱼简历

✏️ 面试刷题神器：面试鸭

一.为什么需要理解设计模式？

前端项目会随着需求迭代变得越来越复杂，设计模式的作用就是提前规避 “后期难改、牵一发动全身” 的坑，设计模式的核心价值：解决 “可维护、可扩展” 问题。

1.工厂模式

工厂模式：通过一个统一的 “工厂函数 / 类” 封装对象的创建逻辑，外界只需传入参数（如类型、配置），即可获取所需实例，无需关心实例内部的构造细节。核心是 “创建逻辑与使用逻辑分离”，实现批量、灵活地创建相似对象。

前端应用场景：

1.Axios 实例

2.Vue实例

3.组件库中的 “表单组件工厂”,统一管理所有表单组件的基础属性（如 id、disabled）

2.单例模式：确保全局只有一个实例

核心是为了解决 “重复创建实例导致的资源浪费、状态混乱、逻辑冲突” 问题—— 当某个对象在系统中只需要 “唯一存在” 时，单例模式能确保全局访问到的是同一个实例，从根源避免多实例带来的隐患。

前端典型场景：

1.Vuex单一store实例

2.浏览器的 window 对象

3.原型模式：通过 “复制” 创建新对象

原型模式的核心是 “基于已有对象（原型）复制创建新对象” —— 不是从零开始定义新对象的属性和方法，而是直接 “拷贝” 一个现有对象（原型）的结构，再根据需要修改差异化内容。

前端中原型模式的本质：依托 JavaScript 原型链。

JavaScript 本身就是基于原型的语言，所有对象都有 __proto__ 属性（指向其原型对象），这是原型模式在前端的 “天然实现”。

普通对象原型属性: 只有'proto'属性。

函数原型属性：proto、prototype属性。

prototype：专属属性，只有函数有，用于 "当函数作为构造函数时，给新创建的实例提供原型"。

原型链顶端： Object.prototype.proto :指向null ;

前端典型场景：

1.Object.create()

2.Vue2 的数组方法重写：Vue2 为数组的push、pop等方法添加响应式逻辑，新数组会继承这些重写后的方法。

3.继承

工厂模式与原型模式区别：

工厂模式：

基于参数 / 规则 “全新创建” 对象；

核心目的：封装复杂的创建逻辑，让调用者无需关心对象构造细节。

原型模式

基于 “已有原型对象” 复制生成新对象

核心目的：复用已有对象的属性 / 方法，减少重复定义，支持继承扩展

4.观察者模式：“一对多” 的依赖通知机制

观察者模式（Observer Pattern）是一种 “一对多” 的依赖关系设计模式：

• 存在一个 “被观察者（Subject）” 和多个 “观察者（Observer）”；


• 当被观察者的状态发生变化时，会自动通知所有依赖它的观察者，并触发观察者的更新逻辑；


• 核心是 “解耦被观察者和观察者”—— 双方无需知道彼此的具体实现，只需通过统一的接口通信

前端典型场景：

1.浏览器事件监听（最基础的观察者模式）

浏览器的 DOM 事件本质是观察者模式的实现：

• 被观察者：DOM 元素（如按钮）；


• 观察者：事件处理函数（onclick、onchange 等）；


• 流程：给元素绑定事件（订阅）→ 元素状态变化（如被点击）→ 自动执行所有绑定的事件处理函数（通知观察者）。


• 观察者模式的核心价值是 “状态变化自动同步”

2.状态管理库（Vuex/Pinia/Redux）

Vuex、Redux 等全局状态管理库的核心机制就是观察者模式：

• 被观察者：Store 中的状态（如 state.user、state.cart）；


• 观察者：依赖该状态的组件；


• 流程：组件订阅状态（mapState 或 useSelector）→ 状态更新（commit 或 dispatch）→ 所有订阅该状态的组件自动重新渲染（收到通知更新）

3. 框架的响应式系统（Vue/React）

Vue 的响应式原理（数据驱动视图）和 React 的状态更新机制，底层都依赖观察者模式：

• Vue：数据对象（data）是被观察者，视图（DOM）和计算属性是观察者 —— 数据变化时，Vue 自动触发依赖收集的观察者（视图重新渲染、计算属性重新计算）。


• React：setState 触发状态更新时，组件树中依赖该状态的组件（观察者）会被重新渲染（收到通知执行更新）。

5.发布-订阅模式

发布 - 订阅模式是观察者模式的变体，核心是通过一个 “中间者（事件中心）” 实现 “发布者” 和 “订阅者” 的完全解耦 —— 发布者不用知道谁在订阅，订阅者也不用知道谁在发布，双方仅通过事件中心传递消息，就像 “报社（发布者）→ 邮局（事件中心）→ 订报人（订阅者）” 的关系。

• 三大角色：
  
  
  
  
  1. 发布者（Publisher） ：负责 “发布事件”（比如触发某个状态变化，如用户登录、数据更新），但不直接联系订阅者；
  
  
  2. 订阅者（Subscriber） ：负责 “订阅事件”（比如关注 “用户登录” 事件），并定义事件触发时的 “回调逻辑”（比如登录后显示欢迎信息）；
  
  
  3. 事件中心（Event Bus） ：中间枢纽，负责存储 “事件 - 订阅者” 的映射关系，接收发布者的事件并通知所有订阅者。
  
  
  
  


• 核心逻辑：订阅者先在事件中心 “订阅” 某个事件 → 发布者在事件中心 “发布” 该事件 → 事件中心找到所有订阅该事件的订阅者，触发它们的回调。

与观察者模式区别：

前端典型场景：

1.跨组件通信（事件总线 Event Bus）

2.全局状态管理（如 Redux 的 Action 机制）

• 发布者：组件通过 dispatch(action) 发布 “状态变更事件”；


• 事件中心：Redux 的 Store，存储状态并管理订阅者；


• 订阅者：组件通过 store.subscribe(() => { ... }) 订阅状态变化，状态更新时重新渲染。

状态管理库到底是观察者模式还是发布 - 订阅模式？

状态管理库（如 Vuex、Redux）之所以会让人觉得 “既是观察者模式，又是发布 - 订阅模式”，是因为它们融合了两种模式的核心思想—— 在底层实现上，既保留了观察者模式 “状态与依赖直接关联” 的特性，又通过 “中间层” 实现了发布 - 订阅模式的 “解耦” 优势，本质是两种模式的结合与优化。

1. 底层：状态与组件的 “观察者模式”（直接依赖）

状态管理库中， “全局状态” 与 “依赖该状态的组件”  之间是典型的观察者模式：

• 被观察者：全局状态（如 Vuex 的 state、Redux 的 store）；


• 观察者：订阅了该状态的组件；


• 逻辑：当状态发生变化时，会直接通知所有依赖它的组件（观察者），触发组件重新渲染。

这一层的核心是 “精准依赖”—— 组件只订阅自己需要的状态（比如 Vue 的 mapState、Redux 的 useSelector），状态变化时只有相关组件会被通知，避免无效更新。

2. 上层：组件与状态的 “发布 - 订阅模式”（解耦通信）

状态管理库中， “组件触发状态变更” 与 “状态变更通知组件”  的过程，通过 “中间层（如 commit/dispatch）” 实现，类似发布 - 订阅模式：

• 发布者：触发状态变更的组件（通过 store.commit('increment') 或 dispatch(action) 发布 “状态变更事件”）；


• 事件中心：状态管理库的核心逻辑（如 Vuex 的 Store 实例、Redux 的 dispatch 机制）；


• 订阅者：依赖状态的组件（通过 subscribe 或计算属性订阅状态）。

这一层的核心是 “解耦”—— 组件不需要知道谁会处理状态变更，也不需要知道哪些组件依赖该状态；状态管理库作为中间层，接收 “发布” 的变更请求，处理后再 “通知” 订阅者，双方完全隔离。

6.代理模式

代理模式（Proxy Pattern）是一种 “通过中间代理对象控制对原始对象的访问” 的设计模式 —— 不直接操作目标对象，而是通过一个 “代理” 来间接访问，代理可以在访问前后添加额外逻辑（如权限校验、缓存、日志记录等）。

核心作用：“控制访问” 与 “增强功能”

前端典型场景：

1. 权限控制代理（限制访问）

2.Vue3响应式核心

用 “中间商” 的思路理解 Vue3 响应式：

• 目标对象：你定义的 data 数据（如 { count: 0, user: { name: '张三' } }）；


• 代理对象：Vue3 通过 reactive() 或 ref() 创建的 “响应式代理”（本质是 Proxy 实例）；


• 调用者：组件中的模板（视图）或业务逻辑（如 {{ count }} 或 count.value++）；


• 代理的 “附加操作” ：拦截数据的读取（get）和修改（set），在读取时 “收集依赖”（记录哪些地方用到了这个数据），在修改时 “触发更新”（通知依赖的地方重新渲染）。

1. 目标对象：原始数据 const target = { count: 0 }; 

2. 依赖收集的容器：记录哪些函数依赖了数据（比如视图渲染函数）

const deps = new Set(); 

3. 创建代理对象（核心：拦截读写，添加响应式逻辑） 

const reactiveProxy = new Proxy(target, 

{

// 拦截“读取数据”操作（如访问 count 时）

get(target, key){

    // 附加操作1：

    收集依赖（假设当前正在执行的函数是依赖） 

    if (currentEffect) { deps.add(currentEffect); // 把依赖存起来 } 

    return target[key]; // 返回原始值 }, 

}

 // 拦截“修改数据”操作（如 count++ 时） 

set(target, key, value) { 

// 更新原始数据 

target[key] = value; 

// 附加操作2：触发更新（通知所有依赖重新执行） 

deps.forEach(effect => effect()); return true; } }); 

}

扩展：Vue3响应式对比vue2响应式

1.Vue2 用的是 Object.defineProperty 拦截属性，只能拦截已存在的属性（对新增属性、数组索引修改不友好）；

具体原因拆解：

Object.defineProperty 的工作方式是给对象的某个具体属性添加 getter/setter。

但数组本质是特殊对象（属性是索引，如 arr[0]、arr[1]），如果用 Object.defineProperty 拦截数组，只能逐个拦截索引（如 0、1），但存在两个致命问题：

1.问题一：无法拦截数组的原生方法（push/pop/splice 等）
数组的常用操作（如 push 新增元素、splice 删除元素）是通过调用数组原型上的方法实现的，这些方法会直接修改数组本身，但 Object.defineProperty 无法拦截 “方法调用”，只能拦截 “属性读写”。所以最终Vue2采取了这7个数组方法的重写。

 arrayMethods[method] = function(...args) {

    // 先调用原生方法（比如 push 实际添加元素）

    const result = arrayProto[method].apply(this, args);

    // 手动触发更新（通知依赖重新渲染）

    notifyUpdate(); 

    return result;

2.问题二：拦截数组索引的成本极高，且不实用。

• 初始化成本高：数组长度可能很大（甚至动态变化），提前拦截所有索引会浪费性能；


• 数组长度变化无法拦截：
  当 arr.length = 0 时，数组会清空所有元素（即删除索引 0、1、2），但 Object.defineProperty 只能知道 length 被改成了 0，无法知道具体哪些元素被删除了。

对于响应式系统来说，需要知道 “哪些元素变化了” 才能精准通知依赖这些元素的视图。但 length 拦截只能知道 “长度变了”，无法定位具体变化的元素，导致依赖这些元素的视图可能不会更新（比如某个视图依赖 arr[0]，length=0 后 arr[0] 不存在了，但视图可能还显示旧值）。

2.Vue3 用 Proxy 直接代理整个对象，能拦截所有属性的读写（包括新增、删除、数组操作），是更彻底、更灵活的代理模式实现，这也是 Vue3 响应式比 Vue2 强大的核心原因之一。

总结

最后想强调：设计模式不是必须遵守的 “规则”，而是解决问题的 “工具”。在实际开发中，我们不需要刻意追求 “用满所有模式”，而是根据场景选择合适的工具：

• 需批量创建对象 → 工厂模式


• 需全局唯一实例 → 单例模式


• .....

参考文章：juejin.cn/post/754253…

最近阅读Android源码，很多地方都涉及到了线程的概念，比如BootAnimation，应用层的线程倒是略懂一二，Framework的线程却是知之甚少，因此特此记录如下：

Android的Native层thread的实现方案一般有两种：

• Linux上的posix线程方案


• Native层面封装的Thread类（用的最多）

posix线程方案

首先创建空文件夹项目-Linux_Thread

其次在Linux_Thread文件夹下创建一个文件thread_posix.c:主要逻辑是在主线程中创建一个子线程mythread，主线程等待子线程执行完毕后，退出进程：

#include <pthread.h>

#include <stdio.h>

#include <stdlib.h>

#include <utils/Log.h>



//线程执行逻辑

void *thread_posix_function(void *arg)

{

	(void*) arg;

	int i;

	for(i = 0; i < 40; i++)

	{

		printf("hello thread i + %d\n", i);

		ALOGD("hello thread i + %d\n", i);

		sleep(1);

	}

	return NULL;

}



int main(void)

{

	

	pthread_t mythread;

	//创建线程并执行

	if(pthread_create(&mythread, NULL, thread_posix_function, NULL))

	{

		ALOGD("error createing thread");

		abort();

	}

	

	sleep(1);

	//等待mythread线程执行结束

	if(pthread_join(mythread, NULL))

	{

		ALOGD("error joining thread");

		abort();

	}

	ALOGD("hello thread has run end exit\n");

	//退出

	exit(0);

}

然后在Linux_Thread文件夹下创建项目构建文件Android.mk中将文件编译为可执行文件：

LOCAL_PATH:=${call my-dir}

include ${CLEAR_VARS}

LOCAL_MODULE := linux_thread

LOCAL_SHARED_LIBRARIES := liblog

LOCAL_SRC_FILES := thread_posix.c

LOCAL_PRELINK_MODULE := false

include ${BUILD_EXECUTABLE}

最后确认Linux_Thread项目位于aosp源码文件夹内，开始编译Linux_Thread项目：

source build/envsetup.sh

lunch

make linux_thread

执行成功后，找到输出的可执行文件linux_thread，将文件push到Android设备中去：

adb push linux_thread /data/local/tmp/

注意如果出现报错 Permission denied,需要对文件进行权限修改：

chmod -R 777 linux_thread

开始启动linux_thread：

./linux_thread

同时也可以通过日志打印输出：

 adb shell locat | grep hello

以上就是posix线程方案的实现。

Native层的Thread类方案

源码分析

Native层即Framework层的C++部分，Thread的相关代码位置

头文件:system/core/libutils/include/utils/Thread.h

源文件:system/core/libutils/Threads.cpp

# system/core/libutils/include/utils/Thread.h

class Thread : virtual public RefBase

{

    public:

    explicit            Thread(bool canCallJava = true);

    virtual             ~Thread();



    virtual status_t    run(    const char* name,

        int32_t priority = PRIORITY_DEFAULT,

        size_t stack = 0);



    virtual void        requestExit();



    virtual status_t    readyToRun();

    

    status_t    requestExitAndWait();



    status_t    join();



    bool        isRunning() const;



    ...

}

Thread继承于RefBase，在构造函数中对canCallJava变量默认赋值为ture，同时声明了一些方法，这些方法都在源文件中实现。

status_t Thread::run(const char* name, int32_t priority, size_t stack)

{

    ...

    if (mRunning) {

        // thread already started

        return INVALID_OPERATION;

    }

    ...

    mRunning = true;



    bool res;

    if (mCanCallJava) {

        res = createThreadEtc(_threadLoop,

                this, name, priority, stack, &mThread);

    } else {

        res = androidCreateRawThreadEtc(_threadLoop,

                this, name, priority, stack, &mThread);

    }



    if (res == false) {

        mStatus = UNKNOWN_ERROR;   // something happened!

        mRunning = false;

        mThread = thread_id_t(-1);

        mHoldSelf.clear();  // "this" may have gone away after this.



        return UNKNOWN_ERROR;

    }

    return OK;



    // Exiting scope of mLock is a memory barrier and allows new thread to run

}



int androidCreateRawThreadEtc(android_thread_func_t entryFunction,

                               void *userData,

                               const char* threadName __android_unused,

                               int32_t threadPriority,

                               size_t threadStackSize,

                               android_thread_id_t *threadId)

{

    ...

    errno = 0;

    pthread_t thread;

    int result = pthread_create(&thread, &attr,

                    (android_pthread_entry)entryFunction, userData);

    pthread_attr_destroy(&attr);

    if (result != 0) {

        ALOGE("androidCreateRawThreadEtc failed (entry=%p, res=%d, %s)\n"

             "(android threadPriority=%d)",

            entryFunction, result, strerror(errno), threadPriority);

        return 0;

    }

    ...

    return 1;

}



int Thread::_threadLoop(void* user)

{

    ...

    bool first = true;



    do {

        bool result;

        //是否第一次执行

        if (first) {

            first = false;

            self->mStatus = self->readyToRun();

            result = (self->mStatus == OK);



            if (result && !self->exitPending()) {

                result = self->threadLoop();

            }

        } else {

            result = self->threadLoop();

        }



        // establish a scope for mLock

        {

        Mutex::Autolock _l(self->mLock);

        //根据结果来跳出循环

        if (result == false || self->mExitPending) {

            self->mExitPending = true;

            self->mRunning = false;

            self->mThread = thread_id_t(-1);

            self->mThreadExitedCondition.broadcast();

            break;

            }

        }

        strong.clear();

        strong = weak.promote();

    } while(strong != nullptr);



    return 0;

}

在run方法中，mCanCallJava变量一般为false，是在thread创建的时候赋值的。从而进入androidCreateRawThreadEtc()方法创建线程，在此函数中，可以看见还是通过pthread_create()方法创建Linux的posix线程（可以理解为Native的Thread就是对posiz的一个封装）；线程运行时回调的函数参数entryFunction值为_threadLoop函数，因此创建的线程会回调到_threadLoop函数中去；_threadLoop函数里则是一个循环逻辑，线程第一次魂环会调用readyToRun()函数，然后再调用threadLoop函数执行线程逻辑，后面就会根据threadLoop执行的结果来判断是否再继续执行下去。

代码练习

头文件MyThread.h

#ifndef _MYTHREAD_H

#define _MYTHREAD_H



#include <utils/threads.h>



namespace android

{

    class MyThread: public Thread

    {

    public:

        MyThread();

        //创建线程对象就会被调用

        virtual void onFirstRef();

        //线程创建第一次运行时会被调用

        virtual status_t readyToRun();

        //根据返回值是否继续执行

        virtual bool threadLoop();

        virtual void requestExit();



    private:

        int hasRunCount = 0;

    };

}

#endif

源文件MyThread.cpp

#define LOG_TAG "MyThread"



#include <utils/Log.h>

#include "MyThread.h"



namespace android

{

    //通过构造函数对mCanCallJava赋值为false

    MyThread::MyThread(): Thread(false)

    {

        ALOGD("MyThread");

    }



    bool MyThread::threadLoop()

    {

        ALOGD("threadLoop hasRunCount = %d", hasRunCount);

        hasRunCount++;

        //计算10次后返回false，表示逻辑结束，线程不需要再继续执行咯

        if(hasRunCount == 10)

        {

            return false;

        }

        return true;

    }



    void MyThread::onFirstRef()

    {

        ALOGD("onFirstRef");

    }



    status_t MyThread::readyToRun()

    {

        ALOGD("readyToRun");

        return 0;

    }



    void MyThread::requestExit()

    {

        ALOGD("requestExit");

    }

}

程序入口Main.cpp

#define LOG_TAG "Main"



#include <utils/Log.h>

#include <utils/threads.h>

#include "MyThread.h"



using namespace android;



int main()

{



    sp<MyThread> thread = new MyThread;

    thread->run("MyThread", PRIORITY_URGENT_DISPLAY);

    while(1)

    {

        if(!thread->isRunning())

        {

            ALOGD("main thread -> isRunning == false");

            break;

        }

    }



    ALOGD("main end");

    return 0;

}

项目构建文件Android.mk

LOCAL_PATH:=${call my-dir}

include ${CLEAR_VARS}

LOCAL_MODULE := android_thread

LOCAL_SHARED_LIBRARIES := libandroid_runtime \

				libcutils \

				libutils \

				liblog

LOCAL_SRC_FILES := MyThread.cpp \

				Main.cpp \

				

LOCAL_PRELINK_MODULE := false

include ${BUILD_EXECUTABLE}

项目目录如下：

通过命令带包得到android_thread可执行文件放入模拟器运行:

最近在做的事情正好需要系统地研究微服务与单体架构的取舍与演进。读到这篇文章《Microservices Are Quietly Dying — And It’s Beautiful》，许多观点直击痛点、非常启发，于是我顺手把它翻译出来，分享给大家，也希望能给同样在复杂性与效率之间权衡的团队一些参考。

微服务正在悄然消亡：这是一件美好的事

为了把我们的创业产品扩展到数百万用户，我们搭建了 47 个微服务。

用户从未达到一百万，但我们达到了每月 23,000 美元的 AWS 账单、长达 14 小时的故障，以及一个再也无法高效交付新功能的团队。

那一刻我才意识到：我们并没有在构建产品，而是在搭建一座分布式的自恋纪念碑。

我们都信过的谎言

五年前，微服务几乎是教条。Netflix 用它，Uber 用它。每一场技术大会、每一篇 Medium 文章、每一位资深架构师都在高喊同一句话：单体不具备可扩展性，微服务才是答案。

于是我们照做了。我们把 Rails 单体拆成一个个服务：用户服务、认证服务、支付服务、通知服务、分析服务、邮件服务；然后是子服务，再然后是调用服务的服务，层层套叠。

到第六个月，我们已经在 12 个 GitHub 仓库里维护 47 个服务。我们的部署流水线像一张地铁图，架构图需要 4K 显示器才能看清。

当“最佳实践”变成“最差实践”

我们不断告诫自己：一切都在运转。我们有 Kubernetes，有服务网格，有用 Jaeger 的分布式追踪，有 ELK 的日志——我们很“现代”。

但那些光鲜的微服务文章从不提的一点是：分布式的隐性税。

每一个新功能都变成跨团队的协商。想给用户资料加一个字段？那意味着要改五个服务、提三个 PR、协调两周，并进行一次像劫案电影一样精心编排的数据库迁移。

我们的预发布环境成本甚至高于生产环境，因为想测试任何东西，都需要把一切都跑起来。47 个服务在 Docker Compose 里同时启动，内存被疯狂吞噬。

那个彻夜崩溃的夜晚

凌晨 2:47，Slack 被消息炸翻。

生产环境宕了。不是某一个服务——是所有服务。支付服务连不上用户服务，通知服务不断超时，API 网关对每个请求都返回 503。

我打开分布式追踪面板：一万五千个 span，全线飘红。瀑布图像抽象艺术。我花了 40 分钟才定位出故障起点。

结果呢？一位初级开发在认证服务上发布了一个配置变更，只是一个环境变量。它让令牌校验多了 2 秒延迟，这个延迟在 11 个下游服务间层层传递，超时叠加、断路器触发、重试逻辑制造请求风暴，整个系统在自身重量下轰然倒塌。

我们搭了一座纸牌屋，却称之为“容错架构”。

我们花了六个小时才修复。并不是因为 bug 复杂——它只是一个配置的单行改动，而是因为排查分布式系统就像破获一桩谋杀案：每个目击者说着不同的语言，而且有一半在撒谎。

那个被忽略的低语

一周后，在复盘会上，我们的 CTO 说了句让所有人不自在的话：

“要不我们……回去？”

回到单体。回到一个仓库。回到简单。

会议室一片沉默。你能感到认知失调。我们是工程师，我们很“高级”。单体是给传统公司和训练营毕业生用的，不是给一家正打造未来的 A 轮初创公司用的。

但随后有人把指标展开：平均恢复时间 4.2 小时；部署频率每周 2.3 次（从单体时代的每周 12 次一路下滑）；云成本增长速度比营收快 40%。

数字不会说谎。是架构在拖垮我们。

美丽的回归

我们用了三个月做整合。47 个服务归并成一个模块划分清晰的 Rails 应用；Kubernetes 变成负载均衡后面的三台 EC2；12 个仓库的工作流收敛成一个边界明确的仓库。

结果简直让人尴尬。

部署时间从 25 分钟降到 90 秒；AWS 账单从 23,000 美元降到 3,800 美元；P95 延迟提升了 60%，因为我们消除了 80% 的网络调用。更重要的是——我们又开始按时交付功能了。

开发者不再说“我需要和三个团队协调”，而是开始说“午饭前给你”。

我们的“分布式系统”变回了结构良好的应用。边界上下文变成 Rails 引擎，服务调用变成方法调用，Kafka 变成后台任务，“编排层”……就是 Rails 控制器。

它更快，它更省，它更好。

我们真正学到的是什么

这是真相：我们为此付出两年时间和 40 万美元才领悟——

微服务不是一种纯粹的架构模式，而是一种组织模式。Netflix 需要它，因为他们有 200 个团队。你没有。Uber 需要它，因为他们一天发布 4,000 次。你没有。

复杂性之所以诱人，是因为它看起来像进步。 拥有 47 个服务、Kubernetes、服务网格和分布式追踪，看起来很“专业”；而一个单体加一套 Postgres，看起来很“业余”。

但复杂性是一种税。它以认知负担、运营开销、开发者幸福感和交付速度为代价。

而大多数初创公司根本付不起这笔税。

我们花了两年时间为并不存在的规模做优化，同时牺牲了能让我们真正达到规模的简单性。

你不需要 50 个微服务，你需要的是自律

软件架构的“肮脏秘密”是：好的设计在任何规模都奏效。

一个结构良好的单体，拥有清晰的模块、明确的边界上下文和合理的关注点分离，比一团由希望和 YAML 勉强粘合在一起的微服务乱麻走得更远。

微服务并不是因为“糟糕”而式微，而是因为我们出于错误的理由使用了它。我们选择了分布式的复杂性而不是本地的自律，选择了运营的负担而不是价值的交付。

那些悄悄回归单体的公司并非承认失败，而是在承认更难的事实：我们一直在解决错误的问题。

所以我想问一个问题：你构建微服务，是在逃避什么？

如果答案是“一个凌乱的代码库”，那我有个坏消息——分布式系统不会修好坏代码，它只会让问题更难被发现。

最近项目做了一个electron项目，记录一下本次客户端热更新中对electron-updater的使用以及遇到的一些问题。

一、配置electron-builder

在electron-builder的配置文件"build"中增加

"publish": [

      {

        "provider": "generic",

        "url": "oss://xxx",

      }

    ]

url: 打包出来的文件存放的地址，配置之后会生成latest.yml文件。electron-updater会去比较这个文件，判断是否需要更新。

二、electron-updater的使用

官方文档： http://www.electron.build/auto-update…

主进程

import { autoUpdater } from "electron-updater";

const { ipcMain } = require("electron");



// 配置提供更新的程序，及build中配置的url

autoUpdater.setFeedURL("oss://xxx")

// 是否自动更新，如果为true，当可以更新时(update-available)自动执行更新下载。

autoUpdater.autoDownload = false



// 1. 在渲染进程里触发获取更新，开始进行更新流程。 (根据具体需求)

ipcMain.on("checkForUpdates", (e, arg) => {

  autoUpdater.checkForUpdates();

});



autoUpdater.on("error", function (error) {

  printUpdaterMessage('error');

  mainWindow.webContents.send("updateError", error);

});



// 2. 开始检查是否有更新

autoUpdater.on("checking-for-update", function () {

  printUpdaterMessage('checking');

});



// 3. 有更新时触发

autoUpdater.on("update-available", function (info) {

  printUpdaterMessage('updateAvailable');

  // 4. 告诉渲染进程有更新，info包含新版本信息

  mainWindow.webContents.send("updateAvailable", info);

});



// 7. 收到确认更新提示，执行下载

ipcMain.on('comfirmUpdate', () => {

  autoUpdater.downloadUpdate()

})



autoUpdater.on("update-not-available", function (info) {

  printUpdaterMessage('updateNotAvailable');

});



// 8. 下载进度，包含进度百分比、下载速度、已下载字节、总字节等

// ps: 调试时，想重复更新，会因为缓存导致该事件不执行，下载直接完成，可找到C:\Users\40551\AppData\Local\xxx-updater\pending下的缓存文件将其删除（这是我本地的路径）

autoUpdater.on("download-progress", function (progressObj) {

  printUpdaterMessage('downloadProgress');

  mainWindow.webContents.send("downloadProgress", progressObj);

});



// 10. 下载完成，告诉渲染进程，是否立即执行更新安装操作

autoUpdater.on("update-downloaded", function () {

    mainWindow.webContents.send("updateDownloaded");

    // 12. 立即更新安装

    ipcMain.on("updateNow", (e, arg) => {

      autoUpdater.quitAndInstall();

    });

  }

);



// 将日志在渲染进程里面打印出来

function printUpdaterMessage(arg) {

  let message = {

    error: "更新出错",

    checking: "正在检查更新",

    updateAvailable: "检测到新版本",

    downloadProgress: "下载中",

    updateNotAvailable: "无新版本",

  };

  mainWindow.webContents.send("printUpdaterMessage", message[arg]??arg);

}

渲染进程:

// 5. 收到主进程可更新的消息，做自己的业务逻辑

ipcRenderer.on('updateAvailable', (event, data) => {

  // do sth.

})



// 6. 点击确认更新

ipcRenderer.send('comfirmUpdate')



// 9. 收到进度信息，做进度条

ipcRenderer.on('downloadProgress', (event, data) => {

  // do sth.

})



// 11. 下载完成，反馈给用户是否立即更新

ipcRenderer.on('updateDownloaded', (event, data) => {

  // do sth.

})



// 12. 告诉主进程，立即更新

ipcRenderer.send("updateNow");

本地环境

如果想在本地环境调试更新，会报错找不到dev-app-update.yml文件
需要自己在根目录(或报错时显示的目录下)手动新建一个dev-app-update.yml里就可以了。文件，将打包生成好的latest.yml复制到dev-app-update.yml里就可以了。

完成截图

嘿，各位 Java 小伙伴们！今天咱们要来聊聊 Spring Boot 里一个超酷炫但又有点让人头疼的家伙 —— 分布式事务。这玩意儿就像是一场大型派对的组织者，要确保派对上所有的活动（操作）要么都顺顺利利地进行，要么就一起取消，绝对不能出现有的活动进行了一半，有的却没开始的尴尬局面。

为啥要有分布式事务

在以前那种单体应用的小世界里，事务处理就像在自己家里整理东西，所有的东西（数据）都在一个地方，要保证操作的一致性很容易。但随着业务越来越复杂，应用变成了分布式的 “大杂烩”，各个服务就像住在不同房子里的小伙伴，这时候再想保证所有操作都一致，就需要分布式事务这个 “超级协调员” 出场啦。

Spring Boot 里的分布式事务支持

Spring Boot 对分布式事务的支持就像是给你配备了一套超级工具包。其中，@Transactional注解大家肯定都很熟悉，在单体应用里它就是事务管理的小能手。但在分布式场景下，我们还有更厉害的武器，比如基于 XA 协议的分布式事务管理器，以及像 Seata 这样的开源框架。

XA 协议的分布式事务管理器

XA 协议就像是一个国际通用的 “交流规则”，它规定了数据库和事务管理器之间怎么沟通。在 Spring Boot 里使用 XA 协议的分布式事务管理器，就像是给各个服务的数据库都请了一个翻译，让它们能准确地交流事务相关的信息。

下面我们来看一段简单的代码示例，假设我们有两个服务，一个是订单服务，一个是库存服务，我们要在创建订单的同时扣减库存，并且保证这两个操作要么都成功，要么都失败。

首先，我们需要配置 XA 数据源，这里以 MySQL 为例：

@Configuration

public class XADataSourceConfig {

    @Bean

    @ConfigurationProperties(prefix = "spring.datasource")

    public DataSourceProperties dataSourceProperties() {

        return new DataSourceProperties();

    }

    @Bean

    public DataSource dataSource() {

        return dataSourceProperties().initializeDataSourceBuilder()

              .type(com.mysql.cj.jdbc.MysqlXADataSource.class)

              .build();

    }

}

然后，配置事务管理器：

@Configuration

public class XATransactionConfig {

    @Autowired

    private DataSource dataSource;

    @Bean

    public PlatformTransactionManager transactionManager() throws SQLException {

        return new JtaTransactionManager(new UserTransactionFactory(), new TransactionManagerFactory(dataSource));

    }

}

接下来，在业务代码里使用@Transactional注解：

@Service

public class OrderService {

    @Autowired

    private OrderRepository orderRepository;

    @Autowired

    private StockService stockService;

    @Transactional

    public void createOrder(Order order) {

        orderRepository.save(order);

        stockService.decreaseStock(order.getProductId(), order.getQuantity());

    }

}

在这个例子里，createOrder方法上的@Transactional注解就像一个 “指挥官”，它会协调订单保存和库存扣减这两个操作，确保它们在同一个事务里执行。

Seata 框架

Seata 就像是一个更智能、更强大的 “事务指挥官”。它有三个重要的组件：TC（Transaction Coordinator）事务协调器、TM（Transaction Manager）事务管理器和 RM（Resource Manager）资源管理器。TC 就像一个调度中心，TM 负责发起和管理事务，RM 则负责管理资源和提交 / 回滚事务。

使用 Seata，我们首先要在项目里引入相关依赖：

<dependency>

    <groupId>com.alibaba.cloud</groupId>

    <artifactId>spring-cloud-starter-alibaba-seata</artifactId>

</dependency>

然后，配置 Seata 客户端：

seata:

  application-id: ${spring.application.name}

  tx-service-group: my_test_tx_group

  enable-auto-data-source-proxy: true

  client:

    rm:

      async-commit-buffer-limit: 10000

      lock:

        retry-interval: 10

        retry-times: 30

        retry-policy-branch-rollback-on-conflict: true

    tm:

      commit-retry-count: 5

      rollback-retry-count: 5

    undo:

      data-validation: true

      log-serialization: jackson

      log-table: undo_log

在业务代码里，我们使用@GlobalTransactional注解来开启全局事务：

@Service

public class OrderService {

    @Autowired

    private OrderRepository orderRepository;

    @Autowired

    private StockService stockService;

    @GlobalTransactional

    public void createOrder(Order order) {

        orderRepository.save(order);

        stockService.decreaseStock(order.getProductId(), order.getQuantity());

    }

}

这里的@GlobalTransactional注解就像是给整个分布式事务场景下了一道 “圣旨”，让所有涉及到的服务都按照统一的事务规则来执行。

总结

分布式事务虽然复杂，但有了 Spring Boot 提供的强大支持，以及像 Seata 这样优秀的框架，我们也能轻松应对。就像掌握了一门高超的魔法，让我们的分布式系统变得更加可靠和强大。希望今天的分享能让大家对 Spring Boot 中的分布式事务有更深入的理解，在开发的道路上一路 “开挂”，解决各种复杂的业务场景。

最近阅读Android源码，很多地方都涉及到了线程的概念，比如BootAnimation，应用层的线程倒是略懂一二，Framework的线程却是知之甚少，因此特此记录如下：

Android的Native层thread的实现方案一般有两种：

• Linux上的posix线程方案


• Native层面封装的Thread类（用的最多）

posix线程方案

首先创建空文件夹项目-Linux_Thread

其次在Linux_Thread文件夹下创建一个文件thread_posix.c:主要逻辑是在主线程中创建一个子线程mythread，主线程等待子线程执行完毕后，退出进程：

#include <pthread.h>

#include <stdio.h>

#include <stdlib.h>

#include <utils/Log.h>



//线程执行逻辑

void *thread_posix_function(void *arg)

{

	(void*) arg;

	int i;

	for(i = 0; i < 40; i++)

	{

		printf("hello thread i + %d\n", i);

		ALOGD("hello thread i + %d\n", i);

		sleep(1);

	}

	return NULL;

}



int main(void)

{

	

	pthread_t mythread;

	//创建线程并执行

	if(pthread_create(&mythread, NULL, thread_posix_function, NULL))

	{

		ALOGD("error createing thread");

		abort();

	}

	

	sleep(1);

	//等待mythread线程执行结束

	if(pthread_join(mythread, NULL))

	{

		ALOGD("error joining thread");

		abort();

	}

	ALOGD("hello thread has run end exit\n");

	//退出

	exit(0);

}

然后在Linux_Thread文件夹下创建项目构建文件Android.mk中将文件编译为可执行文件：

LOCAL_PATH:=${call my-dir}

include ${CLEAR_VARS}

LOCAL_MODULE := linux_thread

LOCAL_SHARED_LIBRARIES := liblog

LOCAL_SRC_FILES := thread_posix.c

LOCAL_PRELINK_MODULE := false

include ${BUILD_EXECUTABLE}

最后确认Linux_Thread项目位于aosp源码文件夹内，开始编译Linux_Thread项目：

source build/envsetup.sh

lunch

make linux_thread

执行成功后，找到输出的可执行文件linux_thread，将文件push到Android设备中去：

adb push linux_thread /data/local/tmp/

注意如果出现报错 Permission denied,需要对文件进行权限修改：

chmod -R 777 linux_thread

开始启动linux_thread：

./linux_thread

同时也可以通过日志打印输出：

 adb shell locat | grep hello

以上就是posix线程方案的实现。

Native层的Thread类方案

源码分析

Native层即Framework层的C++部分，Thread的相关代码位置

头文件:system/core/libutils/include/utils/Thread.h

源文件:system/core/libutils/Threads.cpp

# system/core/libutils/include/utils/Thread.h

class Thread : virtual public RefBase

{

    public:

    explicit            Thread(bool canCallJava = true);

    virtual             ~Thread();



    virtual status_t    run(    const char* name,

        int32_t priority = PRIORITY_DEFAULT,

        size_t stack = 0);



    virtual void        requestExit();



    virtual status_t    readyToRun();

    

    status_t    requestExitAndWait();



    status_t    join();



    bool        isRunning() const;



    ...

}

Thread继承于RefBase，在构造函数中对canCallJava变量默认赋值为ture，同时声明了一些方法，这些方法都在源文件中实现。

status_t Thread::run(const char* name, int32_t priority, size_t stack)

{

    ...

    if (mRunning) {

        // thread already started

        return INVALID_OPERATION;

    }

    ...

    mRunning = true;



    bool res;

    if (mCanCallJava) {

        res = createThreadEtc(_threadLoop,

                this, name, priority, stack, &mThread);

    } else {

        res = androidCreateRawThreadEtc(_threadLoop,

                this, name, priority, stack, &mThread);

    }



    if (res == false) {

        mStatus = UNKNOWN_ERROR;   // something happened!

        mRunning = false;

        mThread = thread_id_t(-1);

        mHoldSelf.clear();  // "this" may have gone away after this.



        return UNKNOWN_ERROR;

    }

    return OK;



    // Exiting scope of mLock is a memory barrier and allows new thread to run

}



int androidCreateRawThreadEtc(android_thread_func_t entryFunction,

                               void *userData,

                               const char* threadName __android_unused,

                               int32_t threadPriority,

                               size_t threadStackSize,

                               android_thread_id_t *threadId)

{

    ...

    errno = 0;

    pthread_t thread;

    int result = pthread_create(&thread, &attr,

                    (android_pthread_entry)entryFunction, userData);

    pthread_attr_destroy(&attr);

    if (result != 0) {

        ALOGE("androidCreateRawThreadEtc failed (entry=%p, res=%d, %s)\n"

             "(android threadPriority=%d)",

            entryFunction, result, strerror(errno), threadPriority);

        return 0;

    }

    ...

    return 1;

}



int Thread::_threadLoop(void* user)

{

    ...

    bool first = true;



    do {

        bool result;

        //是否第一次执行

        if (first) {

            first = false;

            self->mStatus = self->readyToRun();

            result = (self->mStatus == OK);



            if (result && !self->exitPending()) {

                result = self->threadLoop();

            }

        } else {

            result = self->threadLoop();

        }



        // establish a scope for mLock

        {

        Mutex::Autolock _l(self->mLock);

        //根据结果来跳出循环

        if (result == false || self->mExitPending) {

            self->mExitPending = true;

            self->mRunning = false;

            self->mThread = thread_id_t(-1);

            self->mThreadExitedCondition.broadcast();

            break;

            }

        }

        strong.clear();

        strong = weak.promote();

    } while(strong != nullptr);



    return 0;

}

在run方法中，mCanCallJava变量一般为false，是在thread创建的时候赋值的。从而进入androidCreateRawThreadEtc()方法创建线程，在此函数中，可以看见还是通过pthread_create()方法创建Linux的posix线程（可以理解为Native的Thread就是对posiz的一个封装）；线程运行时回调的函数参数entryFunction值为_threadLoop函数，因此创建的线程会回调到_threadLoop函数中去；_threadLoop函数里则是一个循环逻辑，线程第一次魂环会调用readyToRun()函数，然后再调用threadLoop函数执行线程逻辑，后面就会根据threadLoop执行的结果来判断是否再继续执行下去。

代码练习

头文件MyThread.h

#ifndef _MYTHREAD_H

#define _MYTHREAD_H



#include <utils/threads.h>



namespace android

{

    class MyThread: public Thread

    {

    public:

        MyThread();

        //创建线程对象就会被调用

        virtual void onFirstRef();

        //线程创建第一次运行时会被调用

        virtual status_t readyToRun();

        //根据返回值是否继续执行

        virtual bool threadLoop();

        virtual void requestExit();



    private:

        int hasRunCount = 0;

    };

}

#endif

源文件MyThread.cpp

#define LOG_TAG "MyThread"



#include <utils/Log.h>

#include "MyThread.h"



namespace android

{

    //通过构造函数对mCanCallJava赋值为false

    MyThread::MyThread(): Thread(false)

    {

        ALOGD("MyThread");

    }



    bool MyThread::threadLoop()

    {

        ALOGD("threadLoop hasRunCount = %d", hasRunCount);

        hasRunCount++;

        //计算10次后返回false，表示逻辑结束，线程不需要再继续执行咯

        if(hasRunCount == 10)

        {

            return false;

        }

        return true;

    }



    void MyThread::onFirstRef()

    {

        ALOGD("onFirstRef");

    }



    status_t MyThread::readyToRun()

    {

        ALOGD("readyToRun");

        return 0;

    }



    void MyThread::requestExit()

    {

        ALOGD("requestExit");

    }

}

程序入口Main.cpp

#define LOG_TAG "Main"



#include <utils/Log.h>

#include <utils/threads.h>

#include "MyThread.h"



using namespace android;



int main()

{



    sp<MyThread> thread = new MyThread;

    thread->run("MyThread", PRIORITY_URGENT_DISPLAY);

    while(1)

    {

        if(!thread->isRunning())

        {

            ALOGD("main thread -> isRunning == false");

            break;

        }

    }



    ALOGD("main end");

    return 0;

}

项目构建文件Android.mk

LOCAL_PATH:=${call my-dir}

include ${CLEAR_VARS}

LOCAL_MODULE := android_thread

LOCAL_SHARED_LIBRARIES := libandroid_runtime \

				libcutils \

				libutils \

				liblog

LOCAL_SRC_FILES := MyThread.cpp \

				Main.cpp \

				

LOCAL_PRELINK_MODULE := false

include ${BUILD_EXECUTABLE}

项目目录如下：

通过命令带包得到android_thread可执行文件放入模拟器运行:

Flutter中想在滚动体系中实现复杂的效果，肯定逃不开SIlver全家桶，Sliver中提供了很多好用的组件可以实现各种滚动效果，而如果需要实现，QQ好友分组的那种吸顶效果，Flutter可以可以使用SliverPersistentHeader轻松的做到。

带动画的吸顶滑动

那如果需求再复杂一点，吸顶组件滑动的同时还希望增加吸附的动画效果，其实SliverPersistentHeader也可以很轻松的实现。

但是实现这个效果有一个特殊的“Feature”，他会优先消费滑动事件，导致底部滑动没有在我们预期的时机传递给上一级消费。

最近项目中处理这个问题时也没搜到相关的文章，所以今天想来聊聊这个组件的优先消费设计，以及很简单的一个定制效果。

在 Flutter 中，SliverPersistentHeader是实现“滚动时动态变化且可持久化”头部的核心组件，其浮动模式（floating: true）的动画交互（如滚动停止自动吸附、反向滚动立即展开）是通过多组件协同实现的。

瞅瞅源码

SliverPersistentHeader

那就从SliverPersistentHeader开始，让我们看看是如何实现动画的吸顶效果

class SliverPersistentHeader extends StatelessWidget {

  const SliverPersistentHeader({

    super.key,

    required this.delegate,

    this.pinned = false,

    this.floating = false,

  });



  final bool floating;



  @override

  Widget build(BuildContext context) {

    if (floating && pinned) {

      return _SliverFloatingPinnedPersistentHeader(delegate: delegate);

    }

    if (pinned) {

      return _SliverPinnedPersistentHeader(delegate: delegate);

    }

    if (floating) {

      return _SliverFloatingPersistentHeader(delegate: delegate);

    }

    return _SliverScrollingPersistentHeader(delegate: delegate);

  }



  @override

  void debugFillProperties(DiagnosticPropertiesBuilder properties) {

    super.debugFillProperties(properties);

    ....

  }

}

首先这个组件并不直接实现渲染逻辑，而是根据我们传入的flaoting和pinned的配置委派给不同的内部实现类，其中关于floating的有2个内部类分别是_SliverFloatingPinnedPersistentHeader和_SliverFloatingPersistentHeader，两个最后的实现逻辑类似，都会创建同一个Element实现效果。

_SliverFloatingPersistentHeader

以_SliverFloatingPersistentHeader的举例看逻辑

class _SliverFloatingPersistentHeader extends _SliverPersistentHeaderRenderObjectWidget {

  const _SliverFloatingPersistentHeader({

    required super.delegate,

  }) : super(

    floating: true,

  );



  @override

  _RenderSliverPersistentHeaderForWidgetsMixin createRenderObject(BuildContext context) {

    return _RenderSliverFloatingPersistentHeaderForWidgets(

      vsync: delegate.vsync,

      snapConfiguration: delegate.snapConfiguration,

      stretchConfiguration: delegate.stretchConfiguration,

      showOnScreenConfiguration: delegate.showOnScreenConfiguration,

    );

  }



  @override

  void updateRenderObject(BuildContext context, _RenderSliverFloatingPersistentHeaderForWidgets renderObject) {

    renderObject.vsync = delegate.vsync;

    renderObject.snapConfiguration = delegate.snapConfiguration;

    renderObject.stretchConfiguration = delegate.stretchConfiguration;

    renderObject.showOnScreenConfiguration = delegate.showOnScreenConfiguration;

  }

}

其中的核心是createRenderObject和updateRenderObject，后者的作用热重载和更新配置信息，前者的作用的是创建一个_RenderSliverFloatingPersistentHeaderForWidgets，在这个RenderObject它内部处理了复杂的逻辑，例如：

• 响应滚动方向变化；


• 控制 header 出现/消失动画；


• 通过 ScrollPosition.hold() 暂停用户滚动；


• 使用 _FloatingHeaderState 管理动画控制器（AnimationController）。

记住这个RenderObject，后面还会见到它

_SliverPersistentHeaderRenderObjectWidget

可以看到_SliverFloatingPersistentHeader继承于_SliverPersistentHeaderRenderObjectWidget，先看看它的代码

abstract class _SliverPersistentHeaderRenderObjectWidget extends RenderObjectWidget {

  const _SliverPersistentHeaderRenderObjectWidget({

    required this.delegate,

    this.floating = false,

  });



  final SliverPersistentHeaderDelegate delegate;

  final bool floating;



  @override

  _SliverPersistentHeaderElement createElement() => _SliverPersistentHeaderElement(this, floating: floating);



  @override

  _RenderSliverPersistentHeaderForWidgetsMixin createRenderObject(BuildContext context);



  @override

  void debugFillProperties(DiagnosticPropertiesBuilder description) {

    super.debugFillProperties(description);

    description.add(

      DiagnosticsProperty(

        'delegate',

        delegate,

      ),

    );

  }

}

核心逻辑是通过createElement创建了_SliverPersistentHeaderElement，到这里为止刚好对应上flutter渲染树中的三层架构：

简单的说就是：

• _SliverPersistentHeaderRenderObjectWidget 负责描述，


• _SliverPersistentHeaderElement 负责执行，


• _RenderSliverPersistentHeaderForWidgetsMixin 负责绘制。

_SliverPersistentHeaderElement

那这个Element长啥样呢

class _SliverPersistentHeaderElement extends RenderObjectElement {

  _SliverPersistentHeaderElement(

    _SliverPersistentHeaderRenderObjectWidget super.widget, {

    this.floating = false,

  });



  final bool floating;



  @override

  _RenderSliverPersistentHeaderForWidgetsMixin get renderObject => super.renderObject as _RenderSliverPersistentHeaderForWidgetsMixin;



  @override

  void mount(Element? parent, Object? newSlot) {

    super.mount(parent, newSlot);

    renderObject._element = this;

  }



  @override

  void unmount() {

    renderObject._element = null;

    super.unmount();

  }



  @override

  void update(_SliverPersistentHeaderRenderObjectWidget newWidget) {

    ...

  }



  @override

  void performRebuild() {

    super.performRebuild();

    renderObject.triggerRebuild();

  }



  Element? child;



  void _build(double shrinkOffset, bool overlapsContent) {

    owner!.buildScope(this, () {

      final _SliverPersistentHeaderRenderObjectWidget sliverPersistentHeaderRenderObjectWidget = widget as _SliverPersistentHeaderRenderObjectWidget;

      child = updateChild(

        child,

        floating

          ? _FloatingHeader(child: sliverPersistentHeaderRenderObjectWidget.delegate.build(

            this,

            shrinkOffset,

            overlapsContent

          ))

          : sliverPersistentHeaderRenderObjectWidget.delegate.build(this, shrinkOffset, overlapsContent),

        null,

      );

    });

  }



 ...

}

大致的流程是这样的

• RenderSliverPersistentHeader.performLayout() 在滚动时触发；


• 它会调用 _element._build(shrinkOffset, overlapsContent)；


• _build() 会重新构建 header 对应的 Widget；


• 若 floating 模式，则额外包一层 _FloatingHeader；


• 通过 updateChild() 更新或替换当前子 Element；


• 生成的 child 会对应到 renderObject.child。

_FloatingHeader

class _FloatingHeaderState extends State<_FloatingHeader> {

  ScrollPosition? _position;



  @override

  void didChangeDependencies() {

    super.didChangeDependencies();

    if (_position != null) {

      _position!.isScrollingNotifier.removeListener(_isScrollingListener);

    }

    _position = Scrollable.maybeOf(context)?.position;

    if (_position != null) {

      _position!.isScrollingNotifier.addListener(_isScrollingListener);

    }

  }



  @override

  void dispose() {

    if (_position != null) {

      _position!.isScrollingNotifier.removeListener(_isScrollingListener);

    }

    super.dispose();

  }



  RenderSliverFloatingPersistentHeader? _headerRenderer() {

    return context.findAncestorRenderObjectOfType();

  }



  void _isScrollingListener() {

    assert(_position != null);



    // When a scroll stops, then maybe snap the app bar int0 view.

    // Similarly, when a scroll starts, then maybe stop the snap animation.

    // Update the scrolling direction as well for pointer scrolling updates.

    final RenderSliverFloatingPersistentHeader? header = _headerRenderer();

    if (_position!.isScrollingNotifier.value) {

      header?.updateScrollStartDirection(_position!.userScrollDirection);

      // Only SliverAppBars support snapping, headers will not snap.

      header?.maybeStopSnapAnimation(_position!.userScrollDirection);

    } else {

      // Only SliverAppBars support snapping, headers will not snap.

      header?.maybeStartSnapAnimation(_position!.userScrollDirection);

    }

  }



  @override

  Widget build(BuildContext context) => widget.child;

}

这里面监听滚动状态并控制吸附动画的触发/停止，而控制吸附动画的触发和停止的就是RenderSliverFloatingPersistentHeader，也就是前面_RenderSliverFloatingPersistentHeaderForWidgets所继承的类

_RenderSliverFloatingPersistentHeaderForWidgets

void updateScrollStartDirection(ScrollDirection direction) {

  _lastStartedScrollDirection = direction;

}



void maybeStopSnapAnimation(ScrollDirection direction) {

  _controller?.stop();

}



void maybeStartSnapAnimation(ScrollDirection direction) {

  final FloatingHeaderSnapConfiguration? snap = snapConfiguration;

  if (snap == null) {

    return;

  }

  if (direction == ScrollDirection.forward && _effectiveScrollOffset! <= 0.0) {

    return;

  }

  if (direction == ScrollDirection.reverse && _effectiveScrollOffset! >= maxExtent) {

    return;

  }



  _updateAnimation(

    snap.duration,

    direction == ScrollDirection.forward ? 0.0 : maxExtent,

    snap.curve,

  );

  _controller?.forward(from: 0.0);

}



void _updateAnimation(Duration duration, double endValue, Curve curve) {

  assert(

    vsync != null,

    'vsync must not be null if the floating header changes size animatedly.',

  );



  final AnimationController effectiveController =

    _controller ??= AnimationController(vsync: vsync!, duration: duration)

      ..addListener(() {

          if (_effectiveScrollOffset == _animation.value) {

            return;

          }

          _effectiveScrollOffset = _animation.value;

          markNeedsLayout();

        });



  _animation = effectiveController.drive(

    Tween(

      begin: _effectiveScrollOffset,

      end: endValue,

    ).chain(CurveTween(curve: curve)),

  );

}

可以看到核心思路就是： 创建 AnimationController

• 如果 _controller 为空，则创建一个新的，绑定 vsync（防止动画掉帧）；


• 添加监听器，每帧更新 _effectiveScrollOffset 并调用 markNeedsLayout() 通知 RenderObject 重新布局。 创建 Tween + Curve


• _animation 表示 header 从当前偏移量 _effectiveScrollOffset 到目标 endValue 的动画；


• 使用 CurveTween 实现动画曲线（如 easeInOut）。 动画驱动布局


• 每次动画值变化，RenderObject 会重新计算 header 的位置；


• _effectiveScrollOffset 在 Render 层直接影响 layout 时 header 的显示/收缩状态。

那为什么SliverPersistentHeader的滑动会被优先消费呢？

@override

void performLayout() {

  final SliverConstraints constraints = this.constraints;

  final double maxExtent = this.maxExtent;

  final bool overlapsContent = constraints.overlap > 0.0;

  layoutChild(constraints.scrollOffset, maxExtent, overlapsContent: overlapsContent);

  final double effectiveRemainingPaintExtent = math.max(0, constraints.remainingPaintExtent - constraints.overlap);

  final double layoutExtent = clampDouble(maxExtent - constraints.scrollOffset, 0.0, effectiveRemainingPaintExtent);

  final double stretchOffset = stretchConfiguration != null ?

    constraints.overlap.abs() :

    0.0;

  geometry = SliverGeometry(

    scrollExtent: maxExtent,

    paintOrigin: constraints.overlap,

    paintExtent: math.min(childExtent, effectiveRemainingPaintExtent),

    layoutExtent: layoutExtent,

    maxPaintExtent: maxExtent + stretchOffset,

    maxScrollObstructionExtent: minExtent,

    cacheExtent: layoutExtent > 0.0 ? -constraints.cacheOrigin + layoutExtent : layoutExtent,

    hasVisualOverflow: true, // Conservatively say we do have overflow to avoid complexity.

  );

}

其中layoutExtent的计算就是Header “优先消费滚动”的关键：

• constraints.scrollOffset：代表当前 sliver 被上层滚动消耗的距离。


• maxExtent：header 最大高度。


• 当滚动时，scrollOffset 增大 ⇒ layoutExtent 减小 ⇒ header 收起；


• 当滚动向下 ⇒ scrollOffset 减小 ⇒ layoutExtent 增大 ⇒ header 露出。

在header尚未完全隐藏（scrollOffset < maxExtent）之前，layoutExtent仍然大于0，意味着这个Header还在继续“吃掉”scrollOffset，下一个Sliver还拿不到这个滚动距离。

换句话说

Header 在Layout阶段主动根据scrollOffset调整可见高度，并在未完全隐藏时持续消耗滚动距离，导致下层列表“迟迟不动”——这就是“优先消费滑动”的根本原因。

利用机制解决问题

那我们又希望有这层动画效果，又不希望滑动被提前消费应该怎么做呢，思路有很多种

• 重写sliver，去除这层消费


• 手动接收滑动的offset，模仿实现顶部吸附的动画效果


• 利用sliver接收的滑动实现我们需要的动画效果

第一种情况下sliver中的很多类是内部类，需要手动复制出来，成本极高

第二种思路需要手动兼容和原本布局的滑动冲突情况

在最快、最简思路下，第三种方案应该是最优解

class CustomSnapHeaderDemo extends StatefulWidget {

  const CustomSnapHeaderDemo({super.key});



  @override

  State createState() => _CustomSnapHeaderDemoState();

}



class _CustomSnapHeaderDemoState extends State<CustomSnapHeaderDemo> {

  late final ScrollController _scrollController;

  late ScrollPosition _scrollPosition;



  /// header 的高度

  static const double _headerExtent = 120.0;



  @override

  void initState() {

    super.initState();

    _scrollController = ScrollController();



    /// 等待第一帧绘制后再拿到 ScrollPosition

    WidgetsBinding.instance.addPostFrameCallback((_) {

      _scrollPosition = _scrollController.position;

      // 监听滚动状态变化

      _scrollPosition.isScrollingNotifier.addListener(_onScrollStateChanged);

    });

  }



  @override

  void dispose() {

    _scrollPosition.isScrollingNotifier.removeListener(_onScrollStateChanged);

    _scrollController.dispose();

    super.dispose();

  }



  /// 滚动状态监听器

  void _onScrollStateChanged() {

    final isScrolling = _scrollPosition.isScrollingNotifier.value;

    if (!isScrolling) {

      // 滚动停止时触发吸附逻辑

      _maybeSnapHeader();

    }

  }



  /// 自定义吸附逻辑：

  /// 当 header 显示一半以上时，吸附到完全展开；

  /// 否则隐藏到底部。

  void _maybeSnapHeader() {

    // 当前滚动偏移

    final currentOffset = _scrollPosition.pixels;



    // header 最大可滚动距离

    final maxHeaderOffset = _headerExtent / 2;



    // 如果当前偏移量 < headerExtent，说明 header 仍部分可见

    if (currentOffset >= 0 && currentOffset <= maxHeaderOffset) {

      final visibleRatio = 1.0 - (currentOffset / maxHeaderOffset);

      if (visibleRatio > 0.5) {

        // 吸附展开

        _animateTo(0);

      } else {

        // 吸附隐藏

        _animateTo(maxHeaderOffset);

      }

    }

  }



  /// 平滑滚动到目标位置

  void _animateTo(double targetOffset) {

    _scrollController.animateTo(

      targetOffset,

      duration: const Duration(milliseconds: 250),

      curve: Curves.easeOut,

    );

  }



  @override

  Widget build(BuildContext context) {

    return Scaffold(

      appBar: AppBar(title: Text('SliverPersistentHeader Demo')),

      body: CustomScrollView(

        controller: _scrollController,

        slivers: [

          SliverPersistentHeader(

            pinned: true,

            floating: false,

            delegate: _CustomHeaderDelegate(

              extent: _headerExtent,

            ),

          ),



          // 模拟长列表内容

          SliverList.builder(

            itemCount: 50,

            itemBuilder: (context, index) {

              return ListTile(

                title: Text('Item $index'),

              );

            },

          ),

        ],

      ),

    );

  }

}



class _CustomHeaderDelegate extends SliverPersistentHeaderDelegate {

  final double extent;



  _CustomHeaderDelegate({required this.extent});



  @override

  double get minExtent => extent / 2; // 最小高度

  @override

  double get maxExtent => extent; // 最大高度



  @override

  Widget build(BuildContext context, double shrinkOffset, bool overlapsContent) {

    final percent = 1.0 - (shrinkOffset / maxExtent);

    return Container(

      color: Colors.blue,

      alignment: Alignment.center,

      child: const Text(

        '自定义吸附 Header',

        style: TextStyle(

          color: Colors.white,

          fontSize: 22,

          fontWeight: FontWeight.bold,

        ),

      ),

    );

  }



  @override

  bool shouldRebuild(covariant _CustomHeaderDelegate oldDelegate) {

    return oldDelegate.extent != extent;

  }

}

一、选手登场！🎬

🔵 蓝方：synchronized（老牌选手）

// synchronized：Java自带的语法糖

public synchronized void method() {

    // 临界区代码

}



// 或者

public void method() {

    synchronized(this) {

        // 临界区代码

    }

}

特点：

• 📜 JDK 1.0就有了，资历老


• 🎯 简单粗暴，写法简单


• 🤖 JVM级别实现，自动释放


• 💰 免费午餐，不需要手动管理

🔴 红方：ReentrantLock（新锐选手）

// ReentrantLock：JDK 1.5引入

ReentrantLock lock = new ReentrantLock();



public void method() {

    lock.lock();  // 手动加锁

    try {

        // 临界区代码

    } finally {

        lock.unlock();  // 必须手动释放！

    }

}

特点：

• 🆕 JDK 1.5新秀，年轻有活力


• 🎨 功能丰富，花样多


• 🏗️ API级别实现，灵活强大


• ⚠️ 需要手动管理，容易忘记释放

二、底层实现对决 💻

Round 1: synchronized的底层实现

1️⃣ 对象头结构（Mark Word）

Java对象内存布局：

┌────────────────────────────────────┐

│        对象头 (Object Header)       │

│  ┌─────────────────────────────┐   │

│  │   Mark Word (8字节)          │ ← 存储锁信息

│  ├─────────────────────────────┤   │

│  │   类型指针 (4/8字节)         │   │

│  └─────────────────────────────┘   │

├────────────────────────────────────┤

│        实例数据 (Instance Data)     │

├────────────────────────────────────┤

│        对齐填充 (Padding)           │

└────────────────────────────────────┘

Mark Word在不同锁状态下的变化：

64位虚拟机的Mark Word（8字节=64位）



┌──────────────────────────────────────────────────┐

│  无锁状态 (001)                                   │

│  ┌────────────┬─────┬──┬──┬──┐                   │

│  │  hashcode  │ age │0 │01│   未锁定              │

│  └────────────┴─────┴──┴──┴──┘                   │

├──────────────────────────────────────────────────┤

│  偏向锁 (101)                                     │

│  ┌────────────┬─────┬──┬──┬──┐                   │

│  │  线程ID    │epoch│1 │01│   偏向锁              │

│  └────────────┴─────┴──┴──┴──┘                   │

├──────────────────────────────────────────────────┤

│  轻量级锁 (00)                                    │

│  ┌────────────────────────────┬──┐               │

│  │  栈中锁记录指针             │00│  轻量级锁     │

│  └────────────────────────────┴──┘               │

├──────────────────────────────────────────────────┤

│  重量级锁 (10)                                    │

│  ┌────────────────────────────┬──┐               │

│  │  Monitor对象指针            │10│  重量级锁     │

│  └────────────────────────────┴──┘               │

└──────────────────────────────────────────────────┘

2️⃣ 锁升级过程（重点！）

                    锁升级路径

                    

无锁状态              偏向锁              轻量级锁            重量级锁

  │                   │                   │                   │

  │    第一次访问      │    有竞争         │    竞争激烈       │

  ├──────────────→   ├──────────────→   ├──────────────→   │

  │                   │                   │                   │

  │                   │    CAS失败        │    自旋失败       │

  │                   │                   │                   │

  

  🚶 一个人         🚶 还是一个人       🚶🚶 两个人        🚶🚶🚶 一群人

   走路             (偏向这个人)        抢着走             排队走

详细解释：

阶段1：无锁 → 偏向锁

// 第一次有线程访问synchronized块

Thread-1第一次进入：

1. 对象处于无锁状态

2. Thread-1通过CAS在Mark Word中记录自己的线程ID

3. 成功！升级为偏向锁，偏向Thread-1

4. 下次Thread-1再来，发现Mark Word里是自己的ID，直接进入！

   （就像VIP通道，不用检查）✨



生活比喻：

你第一次去常去的咖啡店☕，店员记住了你的脸。

下次你来，店员一看是你，直接给你做你的老口味，不用问！

阶段2：偏向锁 → 轻量级锁

Thread-2也想进入：

1. 发现偏向锁偏向的是Thread-1

2. Thread-1已经退出了，撤销偏向锁

3. 升级为轻量级锁

4. Thread-2通过CAS在栈帧中创建Lock Record

5. CAS将对象头的Mark Word复制到Lock Record

6. CAS将对象头指向Lock Record

7. 成功！获取轻量级锁 🎉



生活比喻：

咖啡店来了第二个客人，店员发现需要排队系统了。

拿出号码牌，谁先抢到谁先点单（自旋CAS）🎫

阶段3：轻量级锁 → 重量级锁

Thread-3、Thread-4、Thread-5也来了：

1. 多个线程竞争，CAS自旋失败

2. 自旋一定次数后，升级为重量级锁

3. 没抢到的线程进入阻塞队列

4. 需要操作系统介入，线程挂起（park）😴



生活比喻：

咖啡店人太多了！需要叫号系统 + 座位等待区。

没叫到号的人坐下来等，不用一直站着抢（操作系统介入）🪑

3️⃣ 字节码层面

public synchronized void method() {

    System.out.println("hello");

}

字节码：

public synchronized void method();

  descriptor: ()V

  flags: ACC_PUBLIC, ACC_SYNCHRONIZED  ← 看这里！方法标记

  Code:

    stack=2, locals=1, args_size=1

       0: getstatic     #2

       3: ldc           #3

       5: invokevirtual #4

       8: return

同步块字节码：

public void method() {

    synchronized(this) {

        System.out.println("hello");

    }

}

public void method();

  Code:

     0: aload_0

     1: dup

     2: astore_1

     3: monitorenter      ← 进入monitor

     4: getstatic     #2

     7: ldc           #3

     9: invokevirtual #4

    12: aload_1

    13: monitorexit       ← 退出monitor

    14: goto          22

    17: astore_2

    18: aload_1

    19: monitorexit       ← 异常时也要退出

    20: aload_2

    21: athrow

    22: return

Round 2: ReentrantLock的底层实现

基于AQS（AbstractQueuedSynchronizer）实现：

// ReentrantLock内部

public class ReentrantLock {

    private final Sync sync;

    

    // 抽象同步器

    abstract static class Sync extends AbstractQueuedSynchronizer {

        // ...

    }

    

    // 非公平锁实现

    static final class NonfairSync extends Sync {

        final void lock() {

            // 先CAS抢一次

            if (compareAndSetState(0, 1))

                setExclusiveOwnerThread(Thread.currentThread());

            else

                acquire(1);  // 进入AQS队列

        }

    }

    

    // 公平锁实现  

    static final class FairSync extends Sync {

        final void lock() {

            acquire(1);  // 直接排队，不插队

        }

    }

}

数据结构：

ReentrantLock

    │

    ├─ Sync (继承AQS)

    │    ├─ state: int (0=未锁，>0=重入次数)

    │    └─ exclusiveOwnerThread: Thread (持锁线程)

    │

    └─ CLH队列

         Head → Node1 → Node2 → Tail

                 ↓       ↓

              Thread2  Thread3

              (等待)   (等待)

三、功能对比大战 ⚔️

🏁 功能对比表

🎯 详细功能对比

1️⃣ 可中断锁

// ❌ synchronized不可中断

Thread t = new Thread(() -> {

    synchronized(lock) {

        // 即使调用t.interrupt()，这里也不会响应

        while(true) {

            // 死循环

        }

    }

});



// ✅ ReentrantLock可中断

Thread t = new Thread(() -> {

    try {

        lock.lockInterruptibly();  // 可响应中断

        // ...

    } catch (InterruptedException e) {

        System.out.println("被中断了！");

    }

});

t.start();

Thread.sleep(100);

t.interrupt();  // 可以中断！

2️⃣ 尝试加锁

// ❌ synchronized没有tryLock

synchronized(lock) {

    // 要么拿到锁，要么一直等

}



// ✅ ReentrantLock可以尝试

if (lock.tryLock()) {  // 尝试获取，不阻塞

    try {

        // 拿到锁了

    } finally {

        lock.unlock();

    }

} else {

    // 没拿到，去做别的事

    System.out.println("锁被占用，我去干别的");

}



// ✅ 还支持超时

if (lock.tryLock(3, TimeUnit.SECONDS)) {  // 等3秒

    try {

        // 拿到了

    } finally {

        lock.unlock();

    }

} else {

    // 3秒还没拿到，放弃

    System.out.println("等太久了，不等了");

}

3️⃣ 公平锁

// ❌ synchronized只能是非公平锁

synchronized(lock) {

    // 后来的线程可能插队

}



// ✅ ReentrantLock可选公平/非公平

ReentrantLock fairLock = new ReentrantLock(true);  // 公平锁

ReentrantLock unfairLock = new ReentrantLock(false);  // 非公平锁（默认）

公平锁 vs 非公平锁：

非公平锁（吞吐量高）：

Thread-1持锁 → Thread-2排队 → Thread-3排队

         ↓

    释放锁！

         ↓

Thread-4刚好来了，直接抢！（插队）✂️

虽然Thread-2先来，但Thread-4先抢到



公平锁（先来后到）：

Thread-1持锁 → Thread-2排队 → Thread-3排队

         ↓

    释放锁！

         ↓

Thread-4来了，但要排队到最后！

Thread-2先到先得 ✅

4️⃣ 多个条件变量

// ❌ synchronized只有一个等待队列

synchronized(lock) {

    lock.wait();    // 只有一个等待队列

    lock.notify();  // 随机唤醒一个

}



// ✅ ReentrantLock可以有多个Condition

ReentrantLock lock = new ReentrantLock();

Condition notFull = lock.newCondition();   // 条件1：未满

Condition notEmpty = lock.newCondition();  // 条件2：非空



// 生产者

lock.lock();

try {

    while (queue.isFull()) {

        notFull.await();  // 等待"未满"条件

    }

    queue.add(item);

    notEmpty.signal();  // 唤醒"非空"条件的线程

} finally {

    lock.unlock();

}



// 消费者

lock.lock();

try {

    while (queue.isEmpty()) {

        notEmpty.await();  // 等待"非空"条件

    }

    queue.remove();

    notFull.signal();  // 唤醒"未满"条件的线程

} finally {

    lock.unlock();

}

四、性能对决 🏎️

JDK 1.5时代：ReentrantLock完胜

JDK 1.5性能测试（100万次加锁）：

synchronized:   2850ms  😓

ReentrantLock:  1200ms  🚀



ReentrantLock快2倍多！

JDK 1.6之后：synchronized反击！

JDK 1.6对synchronized做了大量优化：

• ✅ 偏向锁（Biased Locking）


• ✅ 轻量级锁（Lightweight Locking）


• ✅ 自适应自旋（Adaptive Spinning）


• ✅ 锁粗化（Lock Coarsening）


• ✅ 锁消除（Lock Elimination）

JDK 1.8性能测试（100万次加锁）：

synchronized:   1250ms  🚀

ReentrantLock:  1200ms  🚀



几乎一样了！

优化技术解析

1️⃣ 偏向锁

// 同一个线程反复进入

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

    synchronized(obj) {

        // 偏向锁：第一次CAS，后续直接进入

        // 性能接近无锁！✨

    }

}

2️⃣ 锁消除

public String concat(String s1, String s2) {

    // StringBuffer是线程安全的，有synchronized

    StringBuffer sb = new StringBuffer();

    sb.append(s1);

    sb.append(s2);

    return sb.toString();

}



// JVM发现sb是局部变量，不可能有竞争

// 自动消除StringBuffer内部的synchronized！

// 性能大幅提升！🚀

3️⃣ 锁粗化

// ❌ 原代码：频繁加锁解锁

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

    synchronized(obj) {

        // 很短的操作

    }

}



// ✅ JVM优化后：锁粗化

synchronized(obj) {  // 把锁提到循环外

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

        // 很短的操作

    }

}

五、使用场景推荐 📝

优先使用synchronized的场景

1️⃣ 简单的同步场景

// 简单的计数器

private int count = 0;



public synchronized void increment() {

    count++;

}

2️⃣ 方法级别的同步

public synchronized void method() {

    // 整个方法同步，简单明了

}

3️⃣ 不需要高级功能

// 只需要基本的互斥，不需要tryLock、Condition等

synchronized(lock) {

    // 业务代码

}

优先使用ReentrantLock的场景

1️⃣ 需要可中断的锁

// 可以响应中断，避免死锁

lock.lockInterruptibly();

2️⃣ 需要尝试加锁

// 拿不到锁就去做别的事

if (lock.tryLock()) {

    // ...

}

3️⃣ 需要公平锁

// 严格按照先来后到

ReentrantLock fairLock = new ReentrantLock(true);

4️⃣ 需要多个条件变量

// 生产者-消费者模式

Condition notFull = lock.newCondition();

Condition notEmpty = lock.newCondition();

5️⃣ 需要获取锁的信息

// 查看等待的线程数

int waiting = lock.getQueueLength();

// 查看是否有线程在等待

boolean hasWaiters = lock.hasQueuedThreads();

六、常见坑点 ⚠️

坑1：ReentrantLock忘记unlock

// ❌ 危险！如果中间抛异常，永远不会释放锁

lock.lock();

doSomething();  // 可能抛异常

lock.unlock();  // 不会执行！💣



// ✅ 正确写法

lock.lock();

try {

    doSomething();

} finally {

    lock.unlock();  // 一定会执行

}

坑2：synchronized锁错对象

// ❌ 每次都是新对象，不起作用！

public void method() {

    synchronized(new Object()) {  // 💣 错误！

        // 相当于没加锁

    }

}



// ✅ 正确写法

private final Object lock = new Object();

public void method() {

    synchronized(lock) {

        // ...

    }

}

坑3：锁的粒度太大

// ❌ 锁的范围太大，性能差

public synchronized void method() {  // 整个方法都锁住

    doA();  // 不需要同步

    doB();  // 需要同步

    doC();  // 不需要同步

}



// ✅ 缩小锁范围

public void method() {

    doA();

    synchronized(lock) {

        doB();  // 只锁需要的部分

    }

    doC();

}

七、面试应答模板 🎤

面试官：synchronized和ReentrantLock有什么区别？

你的回答：

主要从实现层面和功能层面两个角度对比：

实现层面：

功能层面，ReentrantLock更强大：

性能对比：

• JDK 1.6之前ReentrantLock性能更好


• JDK 1.6之后synchronized做了大量优化（偏向锁、轻量级锁、锁消除、锁粗化），性能差不多


• synchronized优化包括：无锁→偏向锁→轻量级锁→重量级锁的升级路径

使用建议：

• 简单场景优先synchronized（代码简洁，自动释放）


• 需要高级功能时用ReentrantLock（可中断、超时、公平锁等）

举个例子：
如果只是简单的计数器，用synchronized即可。但如果是银行转账系统，需要可中断、可超时，就应该用ReentrantLock。

八、总结 🎯

选择决策树：

                   需要同步？

                      │

                     Yes

                      │

        ┌─────────────┴─────────────┐

        │                           │

    简单场景                    复杂场景

 (计数器、缓存等)          (可中断、超时等)

        │                           │

   synchronized                ReentrantLock

        │                           │

    ✅ 简单                      ✅ 功能强

    ✅ 自动释放                  ⚠️ 需手动

    ✅ 性能好                    ✅ 灵活

记忆口诀：

简单场景synchronized，

复杂需求ReentrantLock，

性能现在差不多，

根据场景来选择！🎵

最后一句话：

synchronized是"自动挡"🚗，简单好用；

ReentrantLock是"手动挡"🏎️，灵活强大！

1、重组优化的核心思想

• 定义：状态变化时，让尽可能少的可组合函数以尽可能快的速度执行完成。


• 关键词：尽可能少、尽可能快

2、常见重组优化

  其实在前面介绍Compose的时候，我们也多少提到过一些重组优化，这里主要是将前面提到过的重组优化、实际开发中常见错误怎么重组优化以及Compose中还提供了哪些重组优化的API做一次汇总，帮助我们刚上手时“避坑”。

  2.1 控制重组范围：

让状态变化只影响“必要区域”

 2.1.1 拆分复杂的可组合函数： 避免“牵一发而动全身”

• 优化前：因name对象未被缓存，每次重组后都会创建新的对象，进而导致名称Text()在每次点击后都会重组。

点击操作 -> age累加 -> Test()重组 -> 重新创建name -> name Text()重组。

@Composable

fun Test(){

    val name = "Hello world!!"

    //可观察状态

    var age by remember { mutableIntStateOf(18) }



Column {

//名称

        Text(text = name)

        //年龄

        Text(

            modifier = Modifier.clickable(onClick = { //点击后累加

                age++

            } ),

            text = "$age",)

    }

}

• 优化后：点击操作后，与age依赖的函数只有AgeTest()，Test()和NameTest()函数不受其影响。

@Composable

fun Test(){

    Column {

//名称

        NameTest()

        //年龄

        AgeTest()

    }

}



@Composable

fun NameTest() {

    Text(text = "Hello world!!")

}

@Composable

fun AgeTest() {

    //可观察状态

    var age by remember { mutableIntStateOf(18) }

Text(

        modifier = Modifier.clickable(onClick = { //点击后累加

            age++

        } ),

        text = "$age",)

}

 2.1.2 列表用key控制重组颗粒度：避免“批量无效重组”

在使用LazyColumn/LazyRow 未指定 key 时，默认用 “列表索引” 作为标识，列表增删 / 排序时会导致大量无关项重组。

如果我们没有指定key,那么默认key就是index,假如我们删除第一项(index =0),会导致后续所有的索性变更(即都会左移：2->1,1->0)，从而导致全部重组。--此时后面item无内容变化

指定key后，Compose识别后面item无内容变化，不会重组。--重组数量从“N -> 1”

@Composable

fun ProductList(products: List<Product>) {

    LazyColumn(modifier = Modifier.fillMaxSize()) {

        // 指定 key 为 product.id：唯一标识每个列表项

        items(

            items = products,

            key = { product -> product.id }  // 核心优化：用唯一 ID 替代索引

        ) { product ->

            ShopItem(

                product = product,

                isFavorite = false,

                onFavoriteClick = {}

            )

            Divider()

        }

    }

}

  2.2 避免无效重组:    让“不变的状态”不发生重组

在Compose 简介和基础使用1 简介 1.1 背景 2019 年 5 月（首次亮相）在 Google I/O 大会上， - 掘金
中2.4.5.2 保存界面状态方式章节中提到过

  2.2.1 remember

remember 是Compose API提供的缓存接口，避免每次重组时重新创建对象或者重新计算。
如下，“val showName = "Hello world!!--$name"”写法上面分析过，每次点击后name Text()都会发生重组。通过remember 缓存，那么只有name发生变化时name Text()才会重组。

@Composable

fun Test(name: String){

    //状态

    // val showName = "Hello world!!--$name"

    //remember 普通缓存

    val  showName by remember(name) { mutableStateOf("Hello world!!--$name") }

var age by remember { mutableIntStateOf(18) }

    

    // rememberSaveable 跨配置状态缓存

    val  showName by rememberSaveable(name) { mutableStateOf("Hello world!!--$name") }

var age by rememberSaveable { mutableIntStateOf(18) }



Column {

//名称

        Text(text = showName)



        //年龄

        Text(

            modifier = Modifier.clickable(onClick = { //点击后累加

                age++

            } ),

            text = "$age",)

    }

}

  2.2.2 rememberSaveable

rememberSaveable 是Compose API提供的缓存接口，当状态需要在配置变更（如屏幕旋转、语言切换）后保留时，使用 rememberSaveable 可以实现跨配置的状态缓存，避免状态丢失和不必要的重新计算。

如上示例假设showName、age需要在屏幕旋转、语言切换后保留之前状态，那么就可以用rememberSaveable 缓存。

  2.2.3 rememberUpdatedState

副作用生命周期大于状态的变化周期（例如副作用中延迟、循环等），且副作用中需要获取最新的状态值。
分析：- LaunchedEffect(Unit)副作用中使用Unit表示没监听任何状态，所以只在首次重组时创建启动协程，后续重组不会再重新创建新的启动协程，并且旧的协程也不会被打断。

• reportMessage 是可观察状态，内部直接通过副作用使用时，协程捕获到的是这个状态的引用，所以修改后内部延迟也能打印最新的值。而通过参数传递时传递的是具体的值（String），所以不使用rememberUpdatedState只能打印旧值，使用后rememberUpdatedState可以监听值的变化，保证副作用中打印的是最新的值。

@Composable

fun ReportMessageScreen() {

    // 父组件管理的消息状态，可动态更新

    var reportMessage by remember { mutableStateOf("初始消息") }



// 子组件：负责延迟上报消息

    MessageReporter(currentMessage = reportMessage)

    

    LaunchedEffect(Unit) {

delay(5000) // 延迟3秒上报

        // 问题：即使currentMessage已更新，仍会上报初始值

       Log.d("Report", "内部上报: $reportMessage")

    }



    // 按钮：更新消息内容

    Button(onClick = { reportMessage = "用户修改后的新消息" } ) {

Text(reportMessage)

    }



}



@Composable

fun MessageReporter(currentMessage: String) {

    Log.d("Report","MessageReporter----start---")

    // 错误做法：不使用rememberUpdatedState

    LaunchedEffect(Unit) {

delay(5000) // 延迟3秒上报

        // 问题：即使currentMessage已更新，仍会上报初始值

        Log.d("Report", "错误上报: $currentMessage")

    }



// 正确做法：必须使用rememberUpdatedState

    val latestMessage by rememberUpdatedState(currentMessage)

    LaunchedEffect(Unit) {

delay(10000) // 延迟3秒上报

        // 确保上报的是最新值

        Log.d("Report", "正确上报: $latestMessage")

    }

    Log.d("Report","MessageReporter----end---")

}



//日志打印

//初始化

2025-09-11 20:27:26.742  6847-6847   D  MessageReporter----start---

2025-09-11 20:27:26.749  6847-6847   D  MessageReporter----end---

//点击后

2025-09-11 20:27:29.077  6847-6847   D  MessageReporter----start---

2025-09-11 20:27:29.077  6847-6847   D  MessageReporter----end---

//延迟消息

2025-09-11 20:27:32.096  6847-6847   D  错误上报: 初始消息

2025-09-11 20:27:37.098  6847-6847   D  正确上报: 用户修改后的新消息

  2.2.4 derivedStateOf

通过派生状态的结果去重，避免因 “依赖状态频繁变化但结果不变” 导致的重组。

示例：只有当userName和password都不为空时才需要重组按钮

@Composable

fun LoginScreen() {

    // 状态源1：用户名输入

    var username by remember { mutableStateOf("") }

    // 状态源2：密码输入

    var password by remember { mutableStateOf("") }

    

    //错误写法,每次输入username或者password时，isLoginEnabled都会导致按钮重组

    //val isLoginEnabled = username.isNotEmpty() && password.isNotEmpty()

    

    //正确写法 用derivedStateOf组合两个状态，判断按钮是否可点击

    val isLoginEnabled by remember {

        derivedStateOf {

            // 同时依赖username和password两个状态

            username.isNotEmpty() && password.isNotEmpty()

        }

    }

    

     // 依赖isLoginEnabled的按钮

     Button(

        onClick = { /* 登录逻辑 */ },

        enabled = isLoginEnabled

    ) {Text("登录")}

}

   2.2.5 标记稳定类型 :@Stable/@Immutable

自定义数据类未标记稳定类型，Compose 无法判断其是否变化，可能会 “过度谨慎” 地触发重组。
原因：Compose 默认认为 “未标记的自定义类是不稳定的”,即使所有属性都是val。

        2.2.5.1 @Stable/@Immutable 使用

所以如下未标记时，在Test()重组时，即使person对象本身和name、age没有发生变化，都可能导致name Text（）或者age Text()发生重组（过度谨慎重组）

优化方法：添加@Stable/@Immutable标记，防止Compose因过度谨慎带来的不必要的重组。

// 未标记稳定类型的自定义数据类

data class Person(val name: String, val age: Int)



//@Immutable(完全不可变，name和age都是val不可变类型)

//data class Person(val name: String, val age: Int)



//@Stable(稳定类型（不一定完全不可变），name是var可变，age是不可变类型)

//data class Person(var name: String, val age: Int)

@Composable

fun Test(person: Person){

    Column {

//名称

        Text(text = person.name)



        //年龄

        Text(text = "${person.age}",)

    }

}

        2.2.5.2 @Stable/@Immutable 区别

• @Immutable 标记的完全不可变的类，只要引用没变Compose就认为内部数据一定没变，不需要重组。特性：
  
  

  类的所有属性都是val（不可变）

//正确

@Immutable

data class Book(

    val id: Int,          // val 不可变

    val title: String     // val 不可变

)



// 错误：包含 var 属性

@Immutable 

data class Book(

    val id: Int,

    var title: String     // var 可变，违反条件

)



// Book 对象做为Composable入参

@Composable

fun Test(book: Book){

    Column {

//名称

        Text(text = person.title)

    }

}

所有属性类型本身也是不可变的（或被@Immutable标记）

// 自定义不可变类（满足 @Immutable 条件）

@Immutable

data class Author(

    val name: String,     // String 是不可变类型

    val age: Int          // Int 是不可变类型

)



// 引用 @Immutable 类型的属性

@Immutable

data class Book(

    val id: Int,

    val title: String,

    // Author 被 @Immutable 标记，满足条件

    // 如果Author 没有被 @Immutable 标记，则不满足条件

    val author: Author    

)



// 错误：属性类型是可变的 MutableList

@Immutable 

data class Book(

    val id: Int,

    val tags: MutableList<String>  // MutableList 是可变类型，违反条件

)

类本身没有任何可修改状态（包括间接引用对象）

// 最底层：不可变类型

@Immutable

data class Address(

    val city: String,

    val street: String

)



// 中间层：引用不可变类型

@Immutable

data class User(

    val name: String,

    val address: Address  // Address 是 @Immutable 类型

)



// 顶层：引用不可变类型

@Immutable

data class Order(

    val id: Int,

    val user: User        // User 是 @Immutable 类型

)

• @Stable 标记稳定的类（可存在可变属性），引用没变且内部状态能被追踪，Compose就能精准判断只有内部状态发生变化时才触发重组，避免无效重组。特性：
  
  
  
  
  • 类中存在可变属性var
  
  
  • 可变属性必须是可被追踪的
  
  
  
  

@Stable

class User {

    // var age = 18 普通变量，不可追踪、被观察，变化后不会触发重组

    var age by mutableStateOf(18) // 变化可追踪

}



// 用 User 作为入参的 Composable

@Composable

fun UserInfo(user: User) {

    Text("年龄：${user.age}") // 依赖 user.age

}

也就是说要么引用变了（肯定要检查并重组），要么内部状态变了（Compose 能感知到），不会出现引用和内部状态都不变的情况下重组了，也不会出现 “状态变了但 Compose 不知道” 的情况。因此 Compose 可以放心地优化重组逻辑，既不会漏更 UI，也不会做无用功。

       2.2.5.3 总结

使用@Stable/@Immutable标记自定义类目的：因Compose 默认认为 “未标记的自定义类是不稳定的”，可能会发生”过度谨慎“重组。- 添加@Immutable注解完全不可变的类，Compose只有引用对象发生变化时需要重组，自定义类中不可存在可变属性。

• 添加@Stable注解稳定的类（可存在可变属性），Compose只有引用对象发生变化或内部状态发生变化时需要重组，自定义类中允许存在可变属性。

    2.2.6 snapshotFlow      高频防抖

@Composable

fun SearchInput() {

    var searchQuery by remember { mutableStateOf("") }



    // 错误：每次输入字符都会触发重组，直接执行搜索，高频调用

    //LaunchedEffect(searchQuery) {

    //    // 模拟搜索网络请求

    //    Log.d("Search", "搜索：$searchQuery")

    // }



    // 正确：将状态转为Flow，添加300ms防抖，仅停止输入后执行

    LaunchedEffect(Unit) {

        snapshotFlow { searchQuery } // 转换Compose状态为Flow

            .debounce(300) // 防抖：300ms内无变化才继续

            .collect { query ->

                if (query.isNotEmpty()) {

                    Log.d("Search", "搜索：$query") // 仅停止输入后执行

                }

            }

    }





    TextField(

        value = searchQuery,

        onValueChange = { searchQuery = it },

        label = { Text("输入搜索内容") }

    )

}

  2.3 优化重组效率：

让必须重组的过程 “更快”

    2.3.1 减少可组合函数内的耗时操作

可组合函数应只做 “描述 UI” 的轻量操作，禁止在其中直接执行 IO、网络请求、复杂计算。

@Composable

fun UserProfile(userId: String) {

    //错误示例，在组合函数中直接请求网络，每次重组时都会发起网络请求

    //fetchDataFromNetwork() // 网络请求（副作用）

    

    var user by remember { mutableStateOf<User?>(null) }

    

    // 副作用：网络请求，依赖 userId（userId 变化时会重新执行）

    LaunchedEffect(userId) {

        // 耗时操作放在协程中，不阻塞主线程

        user = api.fetchUser(userId) // 网络请求（副作用）

    }

    

    if (user != null) {

        Text("Name: ${user?.name}")

    } else {

        CircularProgressIndicator()

    }

}

    2.3.2 避免在重组中创建新对象

每次重组时创建新对象（如Lambda）会被 Compose 视为 “参数变化”，触发子组件重组。      温故而知新，之前实际开发中也都没注意到这些。- Lambda

//错误示例

@Composable

fun UserProfile(user: User) {

    // 每次重组都会创建新的 Lambda 实例

    Button(onClick = { 

        // 处理点击事件

        navigateToUserDetail(user.id)

    }) {

        Text("查看详情")

    }

}



//正确示例

@Composable

fun UserProfile(user: User) {

    // 无依赖的 remember，仅在首次组合时创建一次 Lambda

    val onClick = remember {

        { navigateToUserDetail(user.id) }

    }

    

    Button(onClick = onClick) {

        Text("查看详情")

    }

}

```

```

沉浸式

所谓沉浸式就是适配状态栏和导航栏，使其和应用内容融为一体，有两种方式：

• 全屏展示应用，隐藏掉状态栏和导航栏，达到沉浸式效果；


• 将状态栏和导航栏设置为透明，应用页面内容的颜色延伸到屏幕边缘，注意这里是内容颜色不是内容本身。

实现方案

创建一个 Android Compose 项目，会默认生成 MainActivity 的代码：

class MainActivity : ComponentActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {

        super.onCreate(savedInstanceState)

        enableEdgeToEdge()

        setContent {

            ImmersiveDemoTheme {

                Scaffold(modifier = Modifier.fillMaxSize()) { innerPadding ->

                    Greeting(

                        name = "Android",

                        modifier = Modifier.padding(innerPadding)

                    )

                }

            }

        }

    }

}

enableEdgeToEdge

在 onCreate 中会默认调用 enableEdgeToEdge()，这个方法是 ComponentActivity 的拓展方法，用来将 Activity 的内容延展到边缘，将状态栏设置为透明，导航栏根据导航模式呈现不同的效果，为这个 Activity 添加一个灰色背景，效果如下：

这是三种导航模式的显示效果，导航模式可以在设置中更改：

可以看出三种导航模式显示效果略有不同，双按钮导航和三按钮导航模式下，导航栏会有系统配置的蒙层。
而手势导航模式下，Activity 内容的背景是延伸到状态栏和导航栏的。

enableEdgeToEdge() 是 ComponentActivity 的拓展方法：

/**

 * 对这个 ComponentActivity 开启边到边的显示

 *

 * 要使用默认样式进行设置，在你的 Activity's onCreate 方法中调用这个方法：

 * ```

 *     override fun onCreate(savedInstanceState: Bundle?) {

 *         enableEdgeToEdge()

 *         super.onCreate(savedInstanceState)

 *         ...

 *     }

 * ```

 * 

 * 默认样式会在系统能够强制实施对比度的时候（在 API 29 及以上版本），把系统栏设置为透明背景。

 * 在旧的平台上（只有 三按钮导航、双按钮导航模式），会应用一个类似的遮光层以确保与系统栏有对比度。

 * See [SystemBarStyle] for more customization options.

 *

 * @param statusBarStyle The [SystemBarStyle] for the status bar.

 * @param navigationBarStyle The [SystemBarStyle] for the navigation bar.

 */

@JvmName("enable")

@JvmOverloads

fun ComponentActivity.enableEdgeToEdge(

    statusBarStyle: SystemBarStyle = SystemBarStyle.auto(Color.TRANSPARENT, Color.TRANSPARENT),

    navigationBarStyle: SystemBarStyle = SystemBarStyle.auto(DefaultLightScrim, DefaultDarkScrim)

) {

    val view = window.decorView

    val statusBarIsDark = statusBarStyle.detectDarkMode(view.resources)

    val navigationBarIsDark = navigationBarStyle.detectDarkMode(view.resources)

    val impl = Impl ?: if (Build.VERSION.SDK_INT >= 29) {

        EdgeToEdgeApi29()

    } else if (Build.VERSION.SDK_INT >= 26) {

        EdgeToEdgeApi26()

    } else if (Build.VERSION.SDK_INT >= 23) {

        EdgeToEdgeApi23()

    } else if (Build.VERSION.SDK_INT >= 21) {

        EdgeToEdgeApi21()

    } else {

        EdgeToEdgeBase()

    }.also { Impl = it }

    impl.setUp(

        statusBarStyle, navigationBarStyle, window, view, statusBarIsDark, navigationBarIsDark

    )

}