当我们编写 new Object() 时，JVM 背后到底发生了怎样的故事？类加载过程中的初始化阶段究竟暗藏哪些玄机？

一、引言：从一段简单代码说起

先来看一个看似简单的 Java 代码片段：

public class HelloWorld {

    public static void main(String[] args) {

        System.out.println("Hello, World!");

    }

}

当我们执行这段代码时，背后却隐藏着 JVM 复杂的类加载机制。.java 文件经过编译变成 .class 字节码文件，这些"静态"的字节码需要被 JVM 动态地加载、处理并最终执行。这就是类加载过程的神奇之处。

类加载机制是 Java 语言的核心基石，它赋予了 Java "一次编写，到处运行" 的能力。理解这一过程，不仅能帮助我们编写更高效的代码，更是面试中的高频考点。

二、类生命周期：七个阶段的完整旅程

在深入类加载过程之前，我们先来了解类的完整生命周期。一个类在 JVM 中从加载到卸载，总共经历七个阶段：

前五个阶段（加载、验证、准备、解析、初始化）统称为类加载过程。

三、类加载过程的五个步骤详解

3.1 加载阶段：寻找类的旅程

加载阶段是类加载过程的起点，主要完成三件事情：

// 示例：不同的类加载方式

public class LoadingExample {

    public static void main(String[] args) throws Exception {

        // 通过类加载器加载

        Class<?> clazz1 = ClassLoader.getSystemClassLoader().loadClass("java.lang.String");

        

        // 通过Class.forName加载（默认会初始化）

        Class<?> clazz2 = Class.forName("java.lang.String");

        

        // 通过字面常量获取（不会触发初始化）

        Class<?> clazz3 = String.class;

        

        System.out.println("三种方式加载的类是否相同: " + 

                          (clazz1 == clazz2 && clazz2 == clazz3));

    }

}

3.2 验证阶段：安全的第一道防线

验证阶段确保 Class 文件的字节流中包含的信息符合《Java虚拟机规范》的全部约束要求，保证这些信息不会危害虚拟机自身的安全。

3.3 准备阶段：零值初始化的奥秘

这是最容易产生误解的阶段！ 在准备阶段，JVM 为**类变量（static变量）**分配内存并设置初始零值，注意这不是程序员定义的初始值。

public class PreparationExample {

    // 准备阶段后 value = 0，而不是 100

    public static int value = 100;

    

    // 准备阶段后 constantValue = 200（因为有final修饰）

    public static final int constantValue = 200;

    

    // 实例变量 - 准备阶段完全不管

    public int instanceValue = 300;

}

各种数据类型的零值对照表：

关键区别：只有**类变量（static变量）**在准备阶段分配内存和初始化零值，实例变量会在对象实例化时随对象一起分配在堆内存中。

3.4 解析阶段：符号引用到直接引用的转换

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。这个过程可以在初始化之后再进行，这是为了支持Java的动态绑定特性。

解析主要针对以下四类符号引用：

3.5 初始化阶段：执行类构造器 <clinit>()

这是类加载过程的最后一步，也是真正开始执行类中定义的Java程序代码的一步。

JVM规范严格规定的六种初始化触发情况：

3.6 使用阶段：类的使命实现

当类完成初始化后，就进入了使用阶段。这是类生命周期中最长的阶段，类的所有功能都可以正常使用：

public class UsageStageExample {

    public static void main(String[] args) {

        // 类已完成初始化，进入使用阶段

        MyClass obj = new MyClass();  // 创建对象实例

        obj.instanceMethod();         // 调用实例方法

        MyClass.staticMethod();       // 调用静态方法

        int value = MyClass.staticVar;// 访问静态变量

    }

}



class MyClass {

    public static int staticVar = 100;

    public int instanceVar = 200;

    

    public static void staticMethod() {

        System.out.println("静态方法");

    }

    

    public void instanceMethod() {

        System.out.println("实例方法");

    }

}

在使用阶段，类可以：

• 创建对象实例


• 调用静态方法和实例方法


• 访问和修改静态字段和实例字段


• 被其他类引用和继承

3.7 卸载阶段：生命的终结

类的卸载是生命周期的最后阶段，但并不是必须发生的。一个类被卸载需要满足以下条件：

public class UnloadingExample {

    public static void main(String[] args) throws Exception {

        // 使用自定义类加载器加载类

        CustomClassLoader loader = new CustomClassLoader();

        Class<?> clazz = loader.loadClass("com.example.TemporaryClass");

        

        // 创建实例并使用

        Object instance = clazz.newInstance();

        System.out.println("类已加载并使用: " + clazz.getName());

        

        // 解除所有引用，使类和类加载器可被回收

        clazz = null;

        instance = null;

        loader = null;

        

        // 触发GC，可能卸载类

        System.gc();

        System.out.println("类和类加载器可能已被卸载");

    }

}



class CustomClassLoader extends ClassLoader {

    // 自定义类加载器实现

}

所以，在 JVM 生命周期内，由 jvm 自带的类加载器加载的类是不会被卸载的。但是由我们自定义的类加载器加载的类是可能被卸载的。

四、关键辨析：类初始化 vs. 对象实例化

这是本文的核心观点，也是大多数开发者容易混淆的概念。让我们通过一个对比表格来清晰区分：

public class InitializationVsInstantiation {

    // 类变量 - 在<clinit>()方法中初始化

    public static String staticField = initStaticField();

    

    // 实例变量 - 在<init>()方法中初始化  

    public String instanceField = initInstanceField();

    

    // 静态代码块 - 在<clinit>()方法中执行

    static {

        System.out.println("静态代码块执行");

    }

    

    // 实例代码块 - 在<init>()方法中执行

    {

        System.out.println("实例代码块执行");

    }

    

    public InitializationVsInstantiation() {

        System.out.println("构造方法执行");

    }

    

    private static String initStaticField() {

        System.out.println("静态变量初始化");

        return "static value";

    }

    

    private String initInstanceField() {

        System.out.println("实例变量初始化");

        return "instance value";

    }

    

    public static void main(String[] args) {

        System.out.println("=== 第一次创建对象 ===");

        new InitializationVsInstantiation();

        

        System.out.println("\n=== 第二次创建对象 ===");

        new InitializationVsInstantiation();

    }

}

输出结果：

静态变量初始化

静态代码块执行

=== 第一次创建对象 ===

实例变量初始化

实例代码块执行

构造方法执行



=== 第二次创建对象 ===

实例变量初始化

实例代码块执行

构造方法执行

五、深度实战：初始化顺序全面解析

现在，让我们通过一个综合示例来回答开篇的思考题：如果一个类同时包含静态变量、静态代码块、实例变量、实例代码块和构造方法，它们的执行顺序是怎样的？在存在继承关系时又会如何变化？

5.1 单类初始化顺序

public class InitializationOrder {

    // 静态变量

    public static String staticField = "静态变量";

    

    // 静态代码块

    static {

        System.out.println(staticField);

        System.out.println("静态代码块");

    }

    

    // 实例变量

    public String field = "实例变量";

    

    // 实例代码块

    {

        System.out.println(field);

        System.out.println("实例代码块");

    }

    

    // 构造方法

    public InitializationOrder() {

        System.out.println("构造方法");

    }

    

    public static void main(String[] args) {

        System.out.println("第一次实例化:");

        new InitializationOrder();

        

        System.out.println("\n第二次实例化:");

        new InitializationOrder();

    }

}

输出结果：

静态变量

静态代码块

第一次实例化:

实例变量

实例代码块

构造方法



第二次实例化:

实例变量

实例代码块

构造方法

关键发现：

5.2 继承关系下的初始化顺序

class Parent {

    // 父类静态变量

    public static String parentStaticField = "父类静态变量";

    

    // 父类静态代码块

    static {

        System.out.println(parentStaticField);

        System.out.println("父类静态代码块");

    }

    

    // 父类实例变量

    public String parentField = "父类实例变量";

    

    // 父类实例代码块

    {

        System.out.println(parentField);

        System.out.println("父类实例代码块");

    }

    

    // 父类构造方法

    public Parent() {

        System.out.println("父类构造方法");

    }

}



class Child extends Parent {

    // 子类静态变量

    public static String childStaticField = "子类静态变量";

    

    // 子类静态代码块

    static {

        System.out.println(childStaticField);

        System.out.println("子类静态代码块");

    }

    

    // 子类实例变量

    public String childField = "子类实例变量";

    

    // 子类实例代码块

    {

        System.out.println(childField);

        System.out.println("子类实例代码块");

    }

    

    // 子类构造方法

    public Child() {

        System.out.println("子类构造方法");

    }

    

    public static void main(String[] args) {

        System.out.println("第一次实例化子类:");

        new Child();

        

        System.out.println("\n第二次实例化子类:");

        new Child();

    }

}

输出结果：

父类静态变量

父类静态代码块

子类静态变量

子类静态代码块

第一次实例化子类:

父类实例变量

父类实例代码块

父类构造方法

子类实例变量

子类实例代码块

子类构造方法



第二次实例化子类:

父类实例变量

父类实例代码块

父类构造方法

子类实例变量

子类实例代码块

子类构造方法

关键发现：

5.3 进阶案例：包含静态变量初始化的复杂情况

public class ComplexInitialization {

    public static ComplexInitialization instance = new ComplexInitialization();

    public static int staticVar = 100;

    public int instanceVar = 200;

    

    static {

        System.out.println("静态代码块: staticVar=" + staticVar);

    }

    

    {

        System.out.println("实例代码块: instanceVar=" + instanceVar + ", staticVar=" + staticVar);

    }

    

    public ComplexInitialization() {

        System.out.println("构造方法: instanceVar=" + instanceVar + ", staticVar=" + staticVar);

    }

    

    public static void main(String[] args) {

        System.out.println("main方法开始");

        new ComplexInitialization();

    }

}

输出结果：

实例代码块: instanceVar=200, staticVar=0

构造方法: instanceVar=200, staticVar=0

静态代码块: staticVar=100

main方法开始

实例代码块: instanceVar=200, staticVar=100

构造方法: instanceVar=200, staticVar=100

关键发现：

六、面试常见问题与解答

6.1 高频面试题解析

Q1: 下面代码的输出结果是什么？为什么？

public class InterviewQuestion {

    public static void main(String[] args) {

        System.out.println(Child.value);

    }

}



class Parent {

    static int value = 100;

    static { System.out.println("Parent静态代码块"); }

}



class Child extends Parent {

    static { System.out.println("Child静态代码块"); }

}

A: 输出结果为：

Parent静态代码块

100

解析： 通过子类引用父类的静态字段，不会导致子类初始化，这是类加载机制的一个重要特性。

Q2: 接口的初始化与类有什么不同？

A: 接口的初始化与类类似，但有重要区别：

6.2 类加载机制的实际应用

1. 单例模式的优雅实现：

public class Singleton {

    private Singleton() {}

    

    private static class SingletonHolder {

        static {

            System.out.println("SingletonHolder初始化");

        }

        private static final Singleton INSTANCE = new Singleton();

    }

    

    public static Singleton getInstance() {

        return SingletonHolder.INSTANCE;

    }

}

这种实现利用了类加载机制的特性：只有在真正调用 getInstance() 时才会加载 SingletonHolder 类，实现了懒加载且线程安全。

2. 常量传播优化：

public class ConstantExample {

    public static final String CONSTANT = "Hello";

    

    public static void main(String[] args) {

        System.out.println(CONSTANT);

    }

}

编译时，常量 CONSTANT 的值会被直接内联到使用处，不会触发类的初始化。

七、总结与思考

通过本文的深入分析，我们可以总结出以下几个关键点：

希望本文能帮助你深入理解JVM类加载机制，下次遇到相关面试题时，相信你一定能游刃有余！

作者：Laurel W

来源：Adobe

作为一名数据科学和数学老师，我其实不介意我的学生使用像 ChatGPT 这样的 LLM，只要它是用来辅助他们学习，而不是取代学习过程。加州理工学院的申请文书指南启发了我为编程和机器学习课制定 AI 使用政策：

哪些是加州理工申请文书中不道德的 AI 使用方式？

• 直接从 AI 生成器复制粘贴


• 依赖 AI 生成内容来列提纲或起草文书


• 用 AI 生成的内容替换你独特的声音和语气


• 翻译用其他语言写的文书

哪些是加州理工申请文书中道德的 AI 使用方式？

• 使用 Grammarly 或 Microsoft Editor 这类 AI 工具检查语法拼写


• 用 AI 生成问题或练习题，帮助启动头脑风暴


• 用 AI 来研究申请流程

如果你还在想你使用 AI 是否道德，问问自己：你请一位值得信赖的大人做同样的事，合适吗？比如请老师帮你改语法错拼写错？当然可以！但让老师帮你写一篇文书草稿，然后你稍微改改就交了？绝对不行。

话虽如此，最近我收到了一些代码作业，一看就完全是 AI 写的，于是我整理了一些“AI 征兆”。当然，人类和 AI 写的代码现在越来越难分辨。但 ChatGPT / Claude / DeepSeek 这些生成的代码，还是有一些共同特征，一看就不对劲。

注释

我希望所有学生都能像 ChatGPT 那样写那么详细的注释吗？当然希望。但他们会吗？肯定不会。

🚩 注释过于详细或者风格怪异，是使用 AI 的信号。

比如，DeepSeek 生成的代码里你会看到用三引号写一段 docstring 来当注释，而不是用标准的 #，尽管那段 docstring 并没有说明参数或返回值：

def find_squares_adding_to_zero(mod):

"""Find two non-zero numbers a and b such that a^2 + b^2 ≡ 0 mod n."""

for a in range(1, mod): # Start from 1 to exclude a = 0

for b in range(a, mod): # Start from a to avoid redundant pairs

if (a2 + b2) % mod == 0:

return (a, b)

return

我觉得这用来注释一行代码的方式很不自然，尤其是我在课上明确教的是用 # 来写单行注释，而这段也不是一个正经的 docstring。

注释里用特殊符号也可能是 AI 写的。除非是我写给很多人看的代码，我自己是不会去找像 “≡” 这样的符号来写注释的。我敢说我的学生大概也不会这么做。

Lambda 表达式

别误会——我喜欢 lambda 表达式，觉得它们是 Python 中很独特且有价值的功能。我认为 lambda 是用来写简洁、临时的小函数的，直接作为参数传给像 map()、filter() 或 sorted() 这种函数才合适。用得好很亮眼。但 lambda 表达式一旦滥用、用错地方，或者还没讲到就乱用，就是个警示。

🚩 lambda 用得不合时宜，说明设计不够认真，或者太依赖 AI。

比如，要是我在还没系统讲 lambda 表达式前，收到这么一份作业代码，那我肯定第一时间就怀疑是 ChatGPT 写的：

from functools import lru_cache

fib = (lambda f: (lambda x: f(f, x)))(lambda self, n:

n if n < 2 else self(self, n-1) + self(self, n-2))

Generate the first 10 Fibonacci numbers

fib_sequence = [fib(n) for n in range(10)]

print(fib_sequence)

这种写法根本不适合用 lambda，而且太复杂了，不可能是一个第一次学 Python 的学生自己写出来的。

库的使用

库导入的位置

🚩 有时候，LLM 会把 import 放在奇怪的位置（不是在文件最上面）。

这种情况我只见过几次，但如果你已经跟学生强调过 import 要放在开头或集中在一起，那这种写法就可疑了。

用了什么库：

🚩 用某个库完成其实不需要它的任务，尤其是没讲过的冷门库，也可能是 AI 写的迹象。

我们再看看上面那段 lambda 代码：

from functools import lru_cache

fib = (lambda f: (lambda x: f(f, x)))(lambda self, n:

n if n < 2 else self(self, n-1) + self(self, n-2))

Generate the first 10 Fibonacci numbers

fib_sequence = [fib(n) for n in range(10)]

print(fib_sequence)

如果你还没讲过 functools 这个库，那学生很可能是用 Google 或 LLM 才知道的。用这些工具探索库当然没问题，但也可能说明实现方式就是 AI 生成的。

命名和格式风格不一致

这个一看就懂。如果作业要求某个字段或变量要用特定命名，AI 写出来的代码往往会给出更泛、更“解释性”的名字，但反而不自然。比如，下面这段找所有小于 n 的素数的代码，一个普通学生可能不会写得这么工整、变量名这么“讲究”：

def sieve_of_eratosthenes(limit):

"""Return a list of all prime numbers less than the given limit."""

if limit <= 2:

return []

Initialize a boolean array to track prime numbers

is_prime = [True] * limit

is_prime[0] = is_prime[1] = False # 0 and 1 are not primes

for num in range(2, int(limit**0.5) + 1):

if is_prime[num]:

Mark multiples of num as non-prime

for multiple in range(num * num, limit, num):

is_prime[multiple] = False

Collect all prime numbers

primes = [num for num, prime in enumerate(is_prime) if prime]

return primes

Example usage

limit = 50 # Change this value to find primes less than a different number

primes = sieve_of_eratosthenes(limit)

print(f"Primes less than {limit}: {primes}")

我自己可能会用 n 而不是 limit，函数名也会更随意些，比如叫 prime_finder。当然，一些特别讲究的学生也可能会写成这样，所以我一般是结合其他迹象一起判断是不是 AI 写的。

逻辑错误

逻辑错误纸面上是最明显的红旗。但实际上很难判断——到底是语言模型出错了，还是学生自己没理解透？

归根结底，LLM 是基于统计的模型，用训练数据学到的模式来预测下一个 token（比如字、词或子词）。它们擅长生成连贯、有上下文的文本，但并不真正理解、也不具备推理或算法思维。这导致它们在需要精确逻辑的任务上容易出错，比如解数学题或者写代码。有时候会给出看上去靠谱但其实错的答案，或者根本没搞清楚复杂的逻辑结构。比如我见过它们在数学题里索引错、没处理边界条件、甚至输出完全错误。

🚩 如果代码有逻辑错误或者推理错误，那可能是 AI 写的。

理想情况下，一个认真点的学生会先检查并修正这些错误再交作业。但实际情况是，很多代码交上来根本不能跑，或者输出就错了。

最后提醒一下，其实很难定一个硬性规则来判断是不是 AI 写的代码，所以我建议老师先别急着指责，而是带着好奇去了解学生的思路。如果我怀疑一个学生太依赖 AI，我可能会让他白板手写一个类似的题目，或者问问他对这个解法的理解。只要引导得当、细节到位，我希望未来能培养出的是会把 AI 当工具，而不是当拐杖的专业人士。

div {

  box-shadow: 0 0 0 5px red, 0 0 0 10px blue;

}

3. 创意设计：对于追求独特风格的网页设计，多重边框提供了无限的创意空间。可以通过调整边框的颜色、宽度、模糊度等参数，创造出各种独特的视觉效果，展现出与众不同的设计风格。

注意事项

2. 兼容性：不同浏览器对box-shadow属性的支持程度略有差异。在使用时，要确保在主流浏览器上进行充分测试，必要时可以添加浏览器前缀来保证兼容性。

CSS 的多重边框特性为前端开发者提供了一种简单而强大的方式来增强网页的视觉效果。通过合理运用这一特性，我们能够打造出更加美观、富有创意的网页界面。希望大家在今后的前端开发中，大胆尝试多重边框，让自己的网页作品更加出彩！

在数学和计算机科学的交汇处，存在着一种令人着迷的几何结构——希尔伯特曲线（Hilbert Curve）。这种由德国数学家大卫·希尔伯特于1891年提出的连续空间填充曲线，不仅挑战了我们对维度的直观认知，更在现代技术领域发挥着举足轻重的作用。

一、初识希尔伯特曲线：维度穿梭的钥匙

希尔伯特曲线的核心在于其空间填充性和连续性。想象一条无限延伸的细线，它以一种巧妙的方式弯曲、折叠，最终能够填满整个二维平面（或更高维度的空间），这就是希尔伯特曲线的魔力。尽管它是连续的，但由于其分形特性，这条曲线在任何一点都不可导。

希尔伯特曲线的构建基于递归的思想。以最经典的二维希尔伯特曲线为例，它从一个正方形开始，将其四等分，然后用一条线段连接这四个小正方形的中心点，形成一个基本的“U”形。接下来，对每个小正方形重复这个过程，不断细分、连接，最终在无限递归下，这条曲线将覆盖整个正方形内的每一个点, 如下图所示。

另一个关键特性是局部性与全局性。 在希尔伯特曲线的映射过程中，相邻的一维线段在高维空间中仍然倾向于保持局部邻近性（尽管并非绝对）。这意味着，在一维序列中相近的点，在二维或三维空间中也往往彼此靠近。

二、希尔伯特曲线家族：多样的空间填充策略

希尔伯特曲线并非孤立存在，它属于一个更大的空间填充曲线家族，每个成员都有其独特的构建方式和应用场景。

三、希尔伯特曲线的深远意义：超越几何的维度

希尔伯特曲线的意义远不止于其几何形态，它在数学、计算机科学、甚至哲学层面都产生了深远的影响。

1. 数学意义：

• 挑战维度直觉： 希尔伯特曲线证明了一维曲线可以覆盖高维空间，颠覆了人们对维度的传统认知。


• 分形几何的早期范例： 它展示了自相似性和无限递归的数学美感，为分形几何的发展奠定了基础。


• 拓扑学应用： 为连续映射和空间压缩提供了理论支持。

2. 计算机科学与工程应用：

• 空间索引： 在数据库中高效处理多维数据（如地图坐标、图像像素），通过希尔伯特排序优化范围查询。


• 图像处理： 将二维图像转换为一维序列，用于压缩或渐进传输。


• 并行计算： 分配高维数据到计算节点时，保持数据的局部性以减少通信开销。


• 路径规划： 机器人导航或PCB布线中，生成覆盖整个区域的连续扫描路径。

3. 哲学与认知影响：

希尔伯特曲线模糊了维度的界限，引发了对“维度”本质的哲学思考，挑战了传统几何学的直观认知。

四、空间填充曲线的对比：各有千秋

从上表可以看出，不同的空间填充曲线在连续性、交叉点、局部性保留等方面各有特点，适用于不同的应用场景。希尔伯特曲线以其良好的局部性保留和无交叉点的特性，在数据库索引和图像处理等领域表现出色。

总结：维度之桥，应用之光

希尔伯特曲线及其变体不仅在理论数学中揭示了维度的奇妙性质，更在计算机科学中成为处理高维数据的关键工具。其核心价值在于将高维问题映射到低维空间并保持局部性，从而在效率和实用性之间找到平衡。随着大数据和人工智能时代的到来，希尔伯特曲线及其衍生技术将在更多领域展现其独特的魅力和应用价值。 无论是理解宇宙的结构，还是优化数据的存储与查询，希尔伯特曲线都为我们提供了一把穿越维度的钥匙，一座连接理论与应用的桥梁。

计算初始化内存总长度

问题背景

在一个系统中，需要执行一系列的内存初始化操作。每次操作都会初始化一个特定地址范围的内存。这些操作范围可能会相互重叠。我们需要计算所有操作完成后，被初始化过的内存空间的总长度。

核心定义

• 操作范围: 每一次内存初始化操作由一个范围 [start, end] 定义，它代表一个左闭右开的区间 [start, end)。这意味着地址 start 被包含，而地址 end 不被包含。


• 内存长度: 对于一个操作 [start, end]，其初始化的内存长度为 end - start。

关键假设

任务要求

给定一组内存初始化操作 cmdsOfMemInit，计算所有操作完成后，被初始化过的内存空间的总长度。这等同于计算所有给定区间的并集的总长度。

输入格式

• cmdsOfMemInit: 一个二维数组（或列表的列表），代表一系列的内存初始化操作。
  
  
  
  
  • 数组长度: 1 <= cmdsOfMemInit.length <= 100000
  
  
  • 每个元素 cmdsOfMemInit[i] 是一个包含两个整数 [start, end] 的数组。
  
  
  • 区间范围: 0 <= start < end <= 10^9
  
  
  
  

输出格式

• 一个整数，表示最终被初始化过的内存空间的总长度。

样例说明

样例 1

• 输入: [[2, 4], [3, 7], [4, 6]]


• 输出: 5


• 解释:
  
  
  
  
  1. 我们有三个区间：[2, 4), [3, 7), [4, 6)。
  
  
  2. 合并 [2, 4) 和 [3, 7) : 因为它们有重叠部分（[3, 4)），所以可以合并成一个更大的区间 [2, 7)。
  
  
  3. 合并 [2, 7) 和 [4, 6) : 新的区间 [4, 6) 完全被 [2, 7) 覆盖。合并后的结果仍然是 [2, 7)。
  
  
  4. 所有操作完成后，最终被初始化的内存区域是 [2, 7)。
  
  
  5. 总长度为 7 - 2 = 5。
  
  
  
  

样例 2

• 输入: [[3, 7], [2, 4], [10, 30]]


• 输出: 25


• 解释:
  
  
  
  
  1. 我们有三个区间：[3, 7), [2, 4), [10, 30)。
  
  
  2. 合并 [3, 7) 和 [2, 4) : 它们有重叠部分，合并后的区间为 [2, 7)。
  
  
  3. 合并 [2, 7) 和 [10, 30) : 这两个区间没有重叠，因为 10 大于 7。它们是两个独立的初始化区域。
  
  
  4. 所有操作完成后，最终的初始化内存区域由两个不相交的区间组成：[2, 7) 和 [10, 30)。
  
  
  5. 总长度是这两个独立区间长度之和：(7 - 2) + (30 - 10) = 5 + 20 = 25。
  
  
  
  

import java.util.ArrayList;

import java.util.Arrays;

import java.util.Comparator;

import java.util.List;



/**

 * 解决“内存空间长度”问题的方案类。

 */

public class Solution {

    /**

     * 计算一系列内存初始化操作覆盖的总内存空间长度。

     *

     * @param cmdsOfMemInit 一个二维数组，每个内部数组 [start, end] 代表一个左闭右开的内存初始化区间。

     * @return 最终初始化的内存空间的总长度。

     */

    public long totalInitializedLength(int[][] cmdsOfMemInit) {

        // --- 1. 处理边界情况 ---

        // 如果输入为空或没有操作，则总长度为 0。

        if (cmdsOfMemInit == null || cmdsOfMemInit.length == 0) {

            return 0;

        }



        // --- 2. 按区间的起始地址（start）对所有操作进行升序排序 ---

        // 这是合并区间的关键前提步骤。

        // Comparator.comparingInt(a -> a[0]) 是一个简洁的写法，表示按内部数组a的第一个元素排序。

        Arrays.sort(cmdsOfMemInit, Comparator.comparingInt(a -> a[0]));



        // --- 3. 合并重叠和连续的区间 ---

        // 使用一个 List 来存储合并后的、不重叠的区间。

        List<int[]> mergedIntervals = new ArrayList<>();

        // 首先将第一个区间（起始地址最小）加入合并列表作为基础。

        mergedIntervals.add(cmdsOfMemInit[0]);



        // 遍历排序后的其余区间

        for (int i = 1; i < cmdsOfMemInit.length; i++) {

            int[] currentInterval = cmdsOfMemInit[i];

            // 获取合并列表中的最后一个区间，用于比较

            int[] lastMerged = mergedIntervals.get(mergedIntervals.size() - 1);



            // 检查当前区间是否与最后一个合并区间重叠或连续。

            // 因为区间是 [start, end) 左闭右开，所以当 currentInterval 的 start <= lastMerged 的 end 时，

            // 它们就需要合并。例如 [2,4) 和 [4,6) 应该合并为 [2,6)。

            if (currentInterval[0] <= lastMerged[1]) {

                // --- 合并区间 ---

                // 如果有重叠/连续，则更新最后一个合并区间的结束地址。

                // 新的结束地址是两个区间结束地址中的较大者。

                // 例如，合并 [2,7) 和 [4,6) 时，新的 end 是 max(7, 6) = 7，结果为 [2,7)。

                lastMerged[1] = Math.max(lastMerged[1], currentInterval[1]);

            } else {

                // --- 不重叠，添加新区间 ---

                // 如果没有重叠，则将当前区间作为一个新的、独立的合并区间添加到列表中。

                mergedIntervals.add(currentInterval);

            }

        }



        // --- 4. 计算合并后区间的总长度 ---

        // 使用 long 类型来存储总长度，防止因数值过大（坐标可达10^9）而溢出。

        long totalLength = 0;

        // 遍历所有不重叠的合并区间

        for (int[] interval : mergedIntervals) {

            // 累加每个区间的长度 (end - start)

            totalLength += (long) interval[1] - interval[0];

        }



        // --- 5. 返回结果 ---

        return totalLength;

    }





    public static void main(String[] args) {

        Solution sol = new Solution();



        // 样例1

        int[][] cmds1 = {{2, 4}, {3, 7}, {4, 6}};

        System.out.println("样例1 输入: [[2, 4], [3, 7], [4, 6]]");

        System.out.println("样例1 输出: " + sol.totalInitializedLength(cmds1)); // 预期: 5



        // 样例2

        int[][] cmds2 = {{3, 7}, {2, 4}, {10, 30}};

        System.out.println("\n样例2 输入: [[3, 7], [2, 4], [10, 30]]");

        System.out.println("样例2 输出: " + sol.totalInitializedLength(cmds2)); // 预期: 25



        // 边界测试

        int[][] cmds3 = {{1, 5}, {6, 10}};

        System.out.println("\n边界测试 输入: [[1, 5], [6, 10]]");

        System.out.println("边界测试 输出: " + sol.totalInitializedLength(cmds3)); // 预期: 8 (4+4)

    }

    */

}

CrossModuleResourceAccess项目

跨模块资源访问-程序包结构-应用框架 - 华为HarmonyOS开发者

根据官方文档和项目实践，以下是关于跨模块资源访问的总结：

1. 跨模块资源访问的核心目标

• 资源共享：通过 HAR（Harmony Archive）和 HSP（Harmony Shared Package）模块，实现资源（如文本、图片、样式等）的复用，减少冗余定义。


• 模块化开发：支持功能模块的独立开发和维护，提升开发效率和代码可维护性。

2. 资源访问方式

• 直接引用：
  
  
  
  • 使用 $r('app.type.name') 或 $rawfile('name') 访问当前模块资源。
  
  
  • 使用 $r('[hsp].type.name') 或 $rawfile('[hsp].name') 访问 HSP 模块资源。
  
  
  
  


• 动态 API 访问：
  
  
  
  • 通过 resourceManager 接口（如 getStringSync、getMediaContentSync）动态获取资源。
  
  
  • 使用 createModuleContext 创建其他模块的上下文，获取其 resourceManager 对象。
  
  
  
  

3. 资源优先级规则

• 优先级从高到低：
  
  
  
  1. 当前模块（HAP/HSP）：自身模块的资源优先级最高。
  
  
  2. 依赖的 HAR/HSP 模块：
     
     
     
     • 如果多个依赖模块中存在同名资源，按照依赖顺序覆盖（依赖顺序靠前的优先级更高）。
     
     
     
     
  
  
  
  

4. 官方文档补充

• 资源隔离与访问控制：
  
  
  
  • 类似腾讯云 CAM（访问管理）的权限设计，HarmonyOS 通过模块化设计实现资源的逻辑隔离。
  
  
  • 开发者可以通过显式依赖和资源命名规范避免冲突。
  
  
  
  


• 跨模块通信：
  
  
  
  • 除了资源访问，还可以通过模块间接口调用实现功能共享。
  
  
  
  

5. 最佳实践

• 命名规范：为资源文件添加模块前缀（如 hsp1_icon.png），避免命名冲突。


• 依赖管理：在 oh-package.json5 中明确模块依赖顺序，确保资源优先级符合预期。


• 动态加载：对于插件化场景，优先使用 resourceManager 动态加载资源。

6. 适用场景

• 多模块共享通用资源（如主题、图标、多语言文本）。


• 动态加载不同模块的资源（如插件化设计）。

如果需要进一步分析具体实现或优化建议，请告诉我！

相关问题

JavaScript事件循环

• 调用栈:这里存放着所有执行中的代码块(函数)。当一个函数被调用时，它被添加到栈中;当返回值被返回时它从栈中被移除。
• 消息队列:当异步事件发生时(如点击事件、文件读取完成等)，对应的回调函数会被添加到消息队列中。如果调用栈为空，事件循环将从队列中取出一个事件处理。
• 微任务队列:与消息队列类似，但处理优先级更高。微任务(如Promise的回调)在当前宏任务执行完毕后、下-个宏任务开始前执行。
• 宏任务与微任务:宏任务包括整体的脚本执行、setTimeout、setlnterval等;微任务包括Promise回调.process.nextTick等。事件循环的每个循环称为一个tick，每个tick会先执行所有可执行的微任务，再执行一个宏任务。

V8引擎中的垃圾回收机制如何工作?

V8引擎使用的垃圾回收策略主要基于“分代收集”(Generational Garbage Collection)的理念:

• 新生代(Young Generation):这部分主要存放生存时间短的小对象。新生代空间较小，使用Scavenge算法进行高效的垃圾回收。Scavenge算法采用复制的方式工作，它将新生代空间分为两半，活动对象存放在一半中，当这一半空间用完时，活动对象会被复制到另一半，非活动对象则被清除。
• 老生代(Old Generation):存放生存时间长或从新生代中晋升的大对象。老生代使用Mark-Sweep(标记-清除)和 Mark-Compact (标记-压缩)算法进行垃圾回收。标记-清除算法在标记阶段标记所有从根节点可达的对象，清除阶段则清除未被标记的对象。标记-压缩算法在清除未标记对象的同时，将存活的对象压缩到内存的一端，减少碎片。

V8 引擎是如何优化其性能的?

V8引擎通过多种方式优化JavaScript的执行性能:

• 即时编译(JIT)：V8将JavaScript代码编译成更高效的机器代码而不是传统的解释执行。V8采用了一个独特的两层编译策略，包括基线编译器(lgnition)和优化编译器(TurboFan)。lgnition生成字节码，这是一个相对较慢但内存使用较少的过程。而 TurboFan 则针对热点代码(执行频率高的代码)进行优化，生成更快的机器代码。
• 内联缓存(lnline Caching)：V8使用内联缓存技术来减少属性访问的时间。当访问对象属性时，V8会在代码中嵌入缓存信息，记录属性的位置，以便后续的属性访问可以直接使用这些信息，避免再次查找，从而加速属性访问。
• 隐藏类(Hidden Classes)：尽管JavaScript是一种动态类型语言，V8引擎通过使用隐藏类来优化对象的存储和访问。每当对象被实例化或修改时，V8会为对象创建或更新隐藏类，这些隐藏类存储了对象属性的布局信息，使得属性访问更加迅速。

引擎基础

冯·诺依曼结构

解释和编译

Java 编译为 class 文件，然后执行

JavaScript 属于解释型语言，它需要在代码执行时，将代码编译为机器语言。

ast (Abstract Syntax Tree)

• Interpreter 逐行读取代码并立即执行。

• Compiler 读取您的整个代码，进行一些优化，然后生成优化后的代码。

JavaScript引擎

JavaScript 其实有众多引擎，只不过v8 是我们最为熟知的。

• V8 （Google），用 C++编写，开放源代码，由 Google 丹麦开发，是 Google Chrome 的一部分，也用于 Node.js.
• JavascriptCore （Apple），开放源代码，用于 webkit 型浏览器，如 Safari，2008年实现了编译器和字节码解释器，升级为了 SquirreFish。苹果内部代号为“Nitro”的 Javascript 引擎也是基于 JavascriptCore 引擎的。
• Rhino，由Mozilla 基金会管理，开放源代码，完全以Java 编写，用于 HTMLUnit
• SpiderMonkey （Mozilla），第一款 Javascript 引擎，早期用于 Netscape Navigator，现时用于 Mozilla Firefox。
• Nodejs 整个架构

:::info 谷歌的Chrome 使用 V8

Safari 使用 JavaScriptCore,

Firefox 使用 SpiderMonkey。

:::

• V8的处理过程
  • 始于从网络中获取 JavaScript 代码。

V8 解析源代码并将其转化为抽象语法树（AST abstract syntax tree）。

- 基于该AST，Ignition 基线解释器可以开始做它的事情，并产生字节码。

- 在这一点上，引擎开始运行代码并收集类型反馈。

- 为了使它运行得更快，字节码可以和反馈数据一起被发送到TurboFan 优化编译器。优化编译器在此基础上做出某些假设，然后产生高度优化的机器代码。

- 如果在某些时候，其中一个假设被证明是不正确的，优化编译器就会取消优化，并回到解释器中。

垃圾回收算法

垃圾回收，又称为：GC （garbage collection）。

GC 即 Garbage Collection，程序工作过程中会产生很多垃圾，这些垃圾是程序不用的内存或者是之前用过了，以后不会再用的内存空间，而GC 就是负责回收垃圾的，因为他工作在引擎内部，所以对于我们前端来说， GC 过程是相对比较无感的，这一套引擎执行而对我们又相对无感的操作也就是常说的垃圾回收机制了当然也不是所有语言都有 GC，一般的高级语言里面会自带GC，比如 Java、Python、Javascript 等，也有无GC的语言，比如C、C++等，那这种就需要我们程序员手动管理内存了，相对比较麻烦

“垃圾”的定义

• “可达性”，有没有被引用，没有被引用的变量，“不可达的变量”
• 变量会在栈中存储，对象在堆中存储
• 我们知道写代码时创建一个基本类型、对象、函数都是需要占用内存的，但是我们并不关注这些，因为这是引擎为我们分配的，我们不需要显式手动的去分配内存，那么 JavaScript 引擎是如何发现并清理垃圾的呢？

引用计数算法

相信这个算法大家都很熟悉，也经常听说。

它的策略是跟踪记录每个变量值被使用的次数

• 当声明了一个变量并且将一个引用类型赋值给该变量的时候这个值的引用次数就为 1 如果同一个值又被赋给另一个变量，那么引用数加1
• 如果该变量的值被其他的值覆盖了，则引用次数減1
• 当这个值的引用次数变为0的时候，说明没有变量在使用，这个值没法被访问了，回收空间，垃圾回收器会在运
• 行的时候清理掉引用次数为0的值占用的内存

:::info 这个算法最怕的就是循环引用（相互引用），还有比如 JavaScript 中不恰当的闭包写法

:::

优点

• 引用计数算法的优点我们对比标记清除来看就会清晰很多，首先引用计数在引用值为0时，也就是在变成垃圾的那一刻就会被回收，所以它可以立即回收垃圾
• 而标记清除算法需要每隔一段时间进行一次，那在应用程序（JS脚本）运行过程中线程就必须要暂停去执行一段时间的GC，另外，标记清除算法需要遍历堆里的活动以及非活动对象来清除，而引用计数则只需要在引用时计数就可以

弊端

• 它需要一个计数器，而此计数器需要占很大的位置，因为我们也不知道被引用数量的上限，还有就是无法解决循环引用无法回收的问题，这也是最严重的

标记清除（Mark-Sweep）算法

:::info 从根对象进行检测，先标记再清除

:::

• 标记清除（Mark-Sweep），目前在 JavaScript引擎里这种算法是最常用的，到目前为止的大多数浏览器的 Javascript引擎都在采用标记清除算法，各大浏览器厂商还对此算法进行了优化加工，且不同浏览器的 Javascript引擎在运行垃圾回收的频率上有所差异。
• 此算法分为标记和清除两个阶段，标记阶段即为所有活动对象做上标记，清除阶段则把没有标记（也就是非活动对象）销毁
• 当变量进入执行环境时，反转某一位（通过一个二进制字符来表示标记），又或者可以维护进入环境变量和离开环境变量这样两个列表，可以自由的把变量从一个列表转移到另一个列表。
• 引擎在执行GC（使用标记清除算法）时，需要从出发点去遍历内存中所有的对象去打标记，而这个出发点有很多， 我们称之为一组根对象，而所谓的根对象，其实在浏览器环境中包括又不止于全局Window对象、文档DOM树
• 整个标记清除算法大致过程就像下面这样：
  • 垃圾收集器在运行时会给内存中的所有变量都加上一个标记，假设内存中所有对象都是垃圾，全标记为0
  • 然后从各个根对象开始遍历，把不是垃圾的节点改成1
  • 清理所有标记为O的垃圾，销毁并回收它们所占用的内存空间
  • 最后，把所有内存中对象标记修改为O，等待下一轮垃圾回收

优点

• 标记清除算法的优点只有一个，那就是实现比较简单，打标记也无非打与不打两种情况，这使得一位二进制位（0和 1）就可以为其标记，非常简单

弊端

• 标记清除算法有一个很大的缺点，就是在清除之后，剩余的对象内存位置是不变的，也会导致空闲内存空间是不连续的，出现了内存碎片（如下图），并且由于剩余空闲内存不是一整块，它是由不同大小内存组成的内存列表，这就牵扯出了内存分配的问题
• 那如何找到合适的块呢？

:::danger 在插入值的时候去解决，最大化使用内存空间，即：通过插入的形式，提升内存空间使用

:::

• 我们可以采取下面三种分配策略
  • First-fit，找到大于等于 size 的块立即返回
  • Best-fit，遍历整个空闲列表，返回大于等于 size 的最小分块
  • Worst-fit，遍历整个空闲列表，找到最大的分块，然后切成两部分，一部分 size 大小，并将该部分返回这三种策略里面 Worst-fit 的空间利用率看起来是最合理，但实际上切分之后会造成更多的小块，形成内存碎片，所以不推荐使用，对于 First-fit 和 Best-fit 来说，考虑到分配的速度和效率 First-fit 是更为明智的选择
• 综上所述，标记清除算法或者说策略就有两个很明显的缺点
  • 内存碎片化，空闲内存块是不连续的，容易出现很多空闲内存块，还可能会出现分配所需内存过大的对象时找不到合适的块
  • 分配速度慢，因为即便是使用 First-fit策略，其操作仍是一个0（n）的操作，最坏情况是每次都要遍历到最后，同时因为碎片化，大对象的分配效率会更慢

:::info 归根结底，标记清除算法的缺点在于清除之后剩余的对象位置不变而导致的空闲内存不连续，所以只要解决这一点，两个缺点都可以完美解决了

:::

标记整理（Mark-Compact）算法

:::color1 有碎片就整理，整理的过程是有消耗的，所以就会有新生代、老生代

:::

• 而标记整理（Mark-Compact）算法就可以有效地解决，它的标记阶段和标记清除算法没有什么不同，只是标记结束后，标记整理算法会将活着的对象（即不需要清理的对象）向内存的一端移动，最后清理掉边界的内存

Unix/windows/Android/iOS系统中内存碎片空间思想

内存碎片化是所有系统都面临的挑战，不同操作系统和环境中的处理策略各有侧重，但也有其共通之处。以下是不同系统在内存碎片处理上的比较：

V8引擎中的标记-整理算法

• 标记阶段：识别未使用的对象，标记为垃圾。
• 整理阶段：将存活对象移动到连续区域，释放大块内存空间，减少外部碎片。

电脑系统（Unix/Linux vs Windows）

• 内存管理：均使用分页机制，但Linux更倾向于预防碎片，Windows依赖内存压缩。
• 处理策略：Linux通过 slab 分配器优化内存分配，Windows通过内存压缩技术。
• 相同点：分页和交换机制，内存不足时回收内存。
• 不同点：Linux更注重预防，Windows依赖内存压缩，处理方式不同。

移动终端（Android vs iOS）

• 内存管理：Android基于Linux，采用内存回收和进程优先级管理；iOS使用更严格的内存管理。
• 处理策略：Android通过Activity生命周期管理内存，iOS通过ARC自动管理。
• 相同点：内存不足时回收内存，依赖垃圾回收机制。
• 不同点：Android更灵活，支持后台进程保活；iOS更严格，强制回收。

内存碎片化挑战

• 内部碎片：内存分配导致的未使用空间，需优化分配策略。
• 外部碎片：分散的空闲空间，需整理或置换策略。
• 处理目标：桌面系统注重稳定性，移动设备关注响应和功耗。

工具与分析

• Unix/Linux：使用top、htop、vmstat等工具。
• Windows：依赖任务管理器和性能监视器。
• 移动设备：Android用Android Profiler，iOS用Instruments。
  总结： 不同系统在内存碎片处理上各有特色，但都旨在优化内存使用效率。V8引擎通过标记-整理减少碎片，而操作系统如Unix/Linux和Windows，以及移动系统如Android和iOS则采用不同的内存管理策略，以适应各自的性能和资源需求。

内存管理

:::info V8的垃圾回收策略主要基于分代式垃圾回收机制，V8中将堆内存分为新生代和老生代两区域，采用不同的垃圾回收器也就是不同的策略管理垃圾回收

:::

新生代

• 当新加入对象时，它们会被存储在使用区。然而，当使用区快要被写满时，垃圾清理操作就需要执行。在开始垃圾回收之前，新生代垃圾回收器会对使用区中的活动对象进行标记。标记完成后，活动对象将会被复制到空闲区并进行排序。然后，垃圾清理阶段开始，即将非活动对象占用的空间清理掉。最后，进行角色互换，将原来的使用区变成空闲区，将原来的空闲区变成使用区。
• 如果一个对象经过多次复制后依然存活，那么它将被认为是生命周期较长的对象，且会被移动到老生代中进行管理。
• 除此之外，还有一种情况，如果复制一个对象到空闲区时，空闲区的空间占用超过了25%，那么这个对象会被直接晋升到老生代空间中。25%比例的设置是为了避免影响后续内存分配，因为当按照 Scavenge 算法回收完成后， 空闲区将翻转成使用区，继续进行对象内存分配。

:::info 一直在开辟空间，达到一定程度，就回晋升到老生代

:::

老生代

• 不同于新生代，老生代中存储的内容是相对使用频繁并且短时间无需清理回收的内容。这部分我们可以使用标记整理进行处理。
• 从一组根元素开始，递归遍历这组根元素，遍历过程中能到达的元素称为活动对象，没有到达的元素就可以判断为非活动对象
• 清除阶段老生代垃圾回收器会直接将非活动对象进行清除。

并行回收

:::info 思想类似于 花两个人的钱，让一个人干三个人的活

:::

全停顿标记

这个概念看字眼好像不好理解，其买如果用前端开发的术语来解释，就是阻塞。

虽然我们的 GC操作被放到了主进程与子进程中去处理，但最终的结果还是主进程被较长时间占用。

在JavaScript的V8引擎中，全停顿标记（Full Stop-the-world Marking）是垃圾回收（GC）过程中的一个重要环节。

这个过程涉及到V8的垃圾回收器暂停JavaScript程序的执行，以便进行垃圾回收的标记阶段。全停顿标记是为了确保在回收内存前正确标记所有活动对象（即正在使用的对象）和非活动对象（即可以清除的对象）。

全停顿标记的工作原理

1.停止执行：当执行到全停顿标记阶段时，V8引擎会暂停正在执行的JavaScript代码，确保没有任何Javascript代码在运行。这个停顿是必需的，因为在标记活动对象时，对象的引用关系需要保持不变。
2. 标记阶段：在这个阶段，垃圾回收器遍历所有根对象（例如全局变量、活跃的函数的局部变量等），从这些根对象开始，递归地访问所有可达的对象。每访问到一个对象，就将其标记为活动（1）的。

3. 恢复执行：标记完成后，V8引擎会恢复JavaScript代码的执行，进入垃圾回收的清除或压缩阶段。

全停顿的影响及优化

全停顿标记虽然对于确保内存被正确管理是必要的，但它会对应用程序的性能产生影响，特别是在垃圾回收发生时， 应用程序的响应时间和性能会短暂下降。为了缓解这种影响，V8引擎采用了几种策略：

• 增量标记 （Incremental Marking）：为了减少每次停顿的时间，V8实现了增量标记，即将标记过程分成多个小部分进行，介于JavaScript执行的间隙中逐步完成标记。

• 并发标记（Concurrent Marking）：V8引擎的更高版本中引入了并发标记，允许垃圾回收标记阶段与JavaScript代码的执行同时进行，进一步减少停顿时间。

• 延迟清理（Lazy Sweeping）：标记完成后的清理阶段也可以延迟执行，按需进行，以减少单次停顿的时间。

这些优化措施有助于提高应用的响应速度和整体性能，特别是在处理大量数据和复杂操作时，确保用户体验不会因垃圾回收而受到较大影响。

切片标记

• 增量就是将一次 GC标记的过程，分成了很多小步，每执行完一小步就让应用逻辑执行一会儿，这样交替多次后完成一轮 GC 标记

三色标记

我们这里的会，表示的是一个中间状态，为什么会有这个中间状态呢？

• 白色指的是未被标记的对象

• 灰色指自身被标记，成员变量（该对象的引用对象）未被标记 • 黑色指自身和成员变量皆被标记

在V8引擎中使用的三色标记算法是一种用于垃圾回收的有效方法，特别是在进行增量和并发标记时。这个算法通过给对象着色（白色、灰色、黑色）来帮助标记和回收垃圾。

工作原理

1. 初始化：

• 白色：初始状态，所有对象都标记为白色，表示这些对象可能是垃圾，如果在标记过程中没有被访问到，最终将被清理。
• 灰色：表示对象已经被标记（访问过），但该对象的引用还没有完全检查完。
• 黑色：表示该对象及其所有引用都已经被完全访问过，并且已经标记。

2. 标记过程：

• 垃圾回收开始时，从根集合（如全局变量、活跃的堆栈帧中的局部变量等）出发，将所有根对象标记为灰色。
• 逐一处理灰色对象：将灰色对象标记为黑色，并将其直接引用的所有白色对象转变为灰色。这个过程不断重复，直到没有灰色对象为止。

3. 扫描完成：

• 所有从根可达的对象最终都会被标记为黑色。所有仍然为白色的对象被认为是不可达的，因此将被视为垃圾并在清除阶段被回收。

优点

• 健壮性：三色标记算法非常适合增量和并发的垃圾回收，因为它能够确保即使在应用程序继续执行的情况下也能正确地标记活动对象。
• 防止漏标：通过灰色和黑色的严格区分，算法确保所有可达的对象都会被遍历和标记，防止错误地回收正在使用的对象。
• 效率：虽然在垃圾回收期间会有增加的计算开销，但三色标记算法可以与应用程序的执行并行进行，减少了GC停顿的时间，提高了应用的响应性和性能。

应用

• 在实际应用中，V8和其他现代JavaScript引擎使用这种算法进行内存管理，优化了动态内存的使用，减少了垃圾回收对应用性能的影响。这对于要求高性能和实时响应的Web应用程序尤其重要。

写屏障（增量中修改引用）

• 这一机制用于处理在增量标记进行时修改引用的处理，可自行修改为灰色

在V8引擎中，写屏障（Write Barrier）是垃圾回收（GC）的一个关键机制，尤其是在增量和并发垃圾回收过程中发挥着至关重要的作用。写屏障主要用来维持垃圾回收中的三色不变性，在对象写操作期间动态地更新对象的可达性信息。

作用

• 保持三色不变性，在使用三色标记算法中，写屏障帮助维持所谓的三色不变性。这意味着系统确保如果一个黑色对象（已经被完全扫描的对象）引用了一个白色对象（尚未被扫描的对象，可能是垃圾），那么这个白色对象应当转变为灰色（标记但尚未扫描完毕的对象），从而避免错误的垃圾回收。
• 处理指针更新，当一个对象的指针被更新（例如，一个对象的属性被另一个对象替换），写屏障确保关于这些对象的垃圾回收元数据得到适当的更新。这是确保垃圾回收器正确识别活动对象和非活动对象的必要步骤。

类型

• Pre-Write Barrier（预写屏障），这种类型的写屏障在实际更新内存之前执行。它主要用于某些特定类型的垃圾回收算法，比如分代垃圾回收，以保持老年代和新生代之间的引用正确性。
• Post-Write Barrier（后写屏障），这是最常见的写屏障类型，发生在对象的指针更新之后。在V8中，当黑色对象指向白色对象时，后写屏障会将该白色对象标记为灰色，确保它不会在当前垃圾回收周期中被错误地回收。

实现细节

• 在V8引擎中，写屏障通常由简短的代码片段实现，这些代码片段在修改对象属性或数组元素时自动执行。例如，每当JavaScript代码或内部的V8代码试图写入一个对象的属性时，写屏障代码会检查是否需要更新垃圾回收的元数据。

惰性清理

• 增量标记只是用于标记活动对象和非活动对象，真正的清理释放内存，则V8采用的是惰性清理（Lazy Sweeping）方案。
• 在增量标记完成后，进行清理。当增量标记完成后，假如当前的可用内存足以让我们快速的执行代码，其实我们是没必要立即清理内存的，可以将清理过程稍微延迟一下，让 Javascript 脚本代码先执行，也无需一次性清理完所有非活动对象内存，可以按需逐一进行清理直到所有的非活动对象内存都清理完毕。

并发回收

:::info 本质是切片，然后去插入，做一些动作

:::

• react 中的 Concurrent 吗？
• 我们想想 React演进过程，是不是就会觉得从并行到并发的演进变得很合了呢？
• 并发挥收其实是更进一步的切片，几乎完全不阻塞主进程。

:::success 分代式机制把一些新、小、存活时间短的对象作为新生代，采用一小块内存频率较高的快速清理，而一些大、老、存活时间长的对象作为老生代，使其很少接受检查，新老生代的回收机制及频率是不同的，可以说此机制的出现很大程度提高了垃圾回收机制的效率

:::

怎么理解内存泄露？

怎么解决内存泄露，代码层面如何优化？

• 减少查找
• 减少变量声明
• 使用 Performance + Memory 分析内存与性能

运行机制

• 浏览器主进程
  • 协调控制其他子进程（创建、销毁）
  • 浏览器界面显示，用户交互，前进、后退、收藏
  • 将渲染进程得到的内存中的Bitmap，绘制到用户界面上
  • 存储功能等
• 第三方插件进程
  • 每种类型的插件对应一个进程，仅当使用该插件时才创建
• GPU进程
  • 用于3D绘制等
• 渲染进程，就是我们说的浏览器内核
  • 排版引擎 Blink 和 JavaScript 引擎V8 都是运行在该进程中，将HTML、CSS和 JavaScript 转换为用户可以与之交互的网页

- 负责页面渲染，脚本执行，事件处理等

- 每个tab页一个渲染进程

- 出于安全考虑，渲染进程都是运行在沙箱模式下

• 网络进程
  • 负责页面的网络资源加载，之前作为一个模块运行在浏览器主进程里面，最近才独立成为一个单独的进程

浏览器事件循环

:::info 在 Chrome 中，事件循环的执行是由浏览器的渲染引擎（例如 Blink）和V8 引擎配合完成的。V8负责 JavaScript 代码的执行，Blink 负责浏览器的渲染和用户界面的更新

:::

执行任务的顺序

先执行当前执行栈同步任务，再执行（微任务），再执行（宏任务）

宏任务

:::info 在 Chrome的源码中，并未直接出现“宏任务”这一术语，但在 Javascript 运行时引擎（V8）以及事件循环 （Event Loop）相关的实现中，宏任务和微任务的概念是非常重要的。

实际上，“宏任务”这一术语来源于 Javascript 事件循环的抽象，它只是帮助我们理解任务的执行顺序和时机。

:::

可以将每次执行栈执行的代码当做是一个宏任务

• I/O
• setTimeout
• setinterval
• setImmediate
• requestAnimationFrame

微任务

当宏任务执行完，会在渲染前，将执行期间所产生的所有微任务都执行完

• process.nextTick
• MutationObserver
• Promise.then catch finally

完整鏊体流程

• 执行当前执行栈同步任务（栈中没有就从事件队列中获取）
• 执行过程中如果遇到微任务，就将它添加到微任务的任务队列中
• 执行栈同步任务执行完毕后，立即执行当前微任务队列中的所有微任务(依次执行)
• 宏任务执行完毕，开始检查渲染，然后 GUI线程接管渲染
• 渲染完毕后， JS线程继续接管，开始下一个宏任务（从事件队列中获取）

Node事件循环机制

与浏览器事件循环机制的不同

• 在 Node.js 中，为了更高效地管理和调度各种类型的异步任务。这种设计使得 Node.js 能够在单线程环境中有效地处理大量的并发任务。下
• Node.js 的事件循环（Event Loop）是一个处理异步操作的机制，它会按照顺序依次执行不同阶段任务。事件循环机制中分为多个阶段，每个阶段都有自己的任务队列，包括：
• Timers 阶段：
  • 处理 setTimeout 和 setInterval 调度的回调函数。
  • 如果指定的时间到了，回调函数会被放入这个队列。
• Pending Callbacks 阶段：
  • 处理一些1/0操作的回调，比如 TCP 错误类型的回调。
  • 这些回调并不完全由开发者控制，而是由操作系统调度的。
• Idle, Prepare 阶段：
  • 仅供内部使用的阶段。
• Poll 阶段：
  • 获取新的1/0事件，执行1/0回调函数。
  • 通常情况下，这个阶段会一直等待，直到有新的！/0 事件到来。
• Check 阶段：
  • 处理 ：setImmediate 调度的回调函数。
  • etImmediate 的回调会在这个阶段执行，比 setTimeout 更早。
• Close Callbacks 阶段：
  • 处理一些关闭的回调函数，比如 socket.on('close', ... ) °

多个队列的必要性

不同类型的异步任务有不同的优先级和处理方式。使用多个队列可以确保这些任务被正确地调度和执行：

• Timers 和 Poll 阶段的区别：
  • setTimeout 和 setInterval 的回调在 Timers 阶段执行，这些回调函数依赖于计时器的到期时间。
  • Poll 阶段处理大多数1/0 回调，这是事件循环的主要阶段，处理大部分异步1/O操作。
• mmediate 与 Timeout 的不同：
  • setImmediate 的回调函数在 Check 阶段执行，这是在当前事件循环周期结束后立即执行。
  • setTimeout 的回调函数则是在 Timers 阶段执行，它可能会延迟到下一个事件循环周期，甚至更久。
• 处理关闭回调：
  • Close Callbacks 阶段专门处理如 socket.on（'close'）这样的回调，以确保在资源释放时执行。

Chrome 任务调度机制

V8与Blink的调度系统密切相关。

:::info Blink 是 Chrome 中的渲染引擎

V8是 Chrome 中的 JavaScript 引擎

:::

Blink 是 Chrome 浏览器中的渲染引擎，负责页面的渲染和绘制任务。V8与 Blink 会协同工作，确保 JavaScript 的执行与页面渲染能够平稳进行。

Blink Scheduler：docs.google.com/document/d/…

接下来我们了解一下 Blink scheduler，一个用于优化 Blink 主线程任务调度的方案，旨在解决现有调度系统中的一些问题。

将任务不断安排到主线程的消息循环中，会导致Blink 主线程阻塞。造成诸多问题：

• 有限的优先级设置-任务按照发布顺序执行，或者可以明确地延迟，但这可能导致一些重要的任务（如输入处理） 被不那么紧急的任务占用优先执行权。
• 缺乏与系统其他部分的协调-比如图形管线虽然已知有输入事件的传递、显示刷新等时序要求，但这些信息无法及时传递给Blink。
• 无法适应不同的使用场景 -某些任务（如垃圾回收）在用户交互时进行非常不合适。

为了解决以上问题，出现了 Blink Scheduler 调度器，它能够更灵活控制任务按照给定优先级执行

• 关键特点
  • 调度器的主要功能是决定在特定时刻哪个任务应当执行。
  • 调度器提供了更高级的API替代现有的主线程任务调度接口，任务不再是抽象的回调函数，而是更具体、具有明确标签和元数据的对象。例如，输入任务会被明确标记，并附带附加元数据。
  • 调度器可以根据系统状态做出更明智的任务决策，而不是依赖给定死的静态优先级。

gitlab.mpi-klsb.mpg.de/eweyulu/qui…

• 性能验证和工具
• 为了验证调度器的效果，文章提到了多项基准测试和性能指标，例如：
  • 队列等待时间：衡量任务从发布到执行的延迟。
  • 输入事件延迟：衡量输入事件的处理时间。
  • 渲染平滑度（jank）：衡量渲染的平滑性，避免出现卡顿。
  • 页面加载时间：跟踪页面加载时间的变化。

其他资料

• V8：v8.dev/docs/torque
• chromium 中promise：chromium.googlesource.com/v8/v8/+/ref…
• V8定义：chromium.googlesource.com/v8/v8/+/ref…
• Node V8：nodejs.org/en/learn/ge…
• ibuv-in-node-js：http://www.geeksforgeeks.org/libuv-in-no…
• Faster JavaScript calls：v8.dev/blog/adapto…
• blink scheduler：docs.google.com/document/d/…

作者：若梦plus
来源：juejin.cn/post/7493386024878833715

Go 语言未来会取代 Java 吗？

（八年 Java 开发的深度拆解：从业务场景到技术底层）

开篇：面试官的灵魂拷问与行业焦虑

前年面某大厂时，技术负责人突然抛出问题：“如果让你重构公司核心系统，会选 Go 还是 Java？”

作为写了八年 Java 的老开发，我本能地想强调 Spring 生态和企业级成熟度，但对方随即展示的 PPT 让我冷汗直冒 —— 某金融公司用 Go 重构交易系统后，QPS 从 5 万飙升到 50 万，服务器成本降低 70%。这让我陷入沉思：当云原生和 AI 浪潮来袭，Java 真的要被 Go 取代了吗？

今天从 业务场景、技术本质、行业趋势 三个维度，结合实战代码和踩坑经验，聊聊我的真实看法。

一、业务场景对比：Go 的 “闪电战” vs Java 的 “持久战”

先看三个典型业务场景，你会发现两者的差异远不止 “性能” 二字。

场景 1：高并发抢购（电商大促）

Go 实现（Gin 框架） ：

func main() {

    router := gin.Default()

    router.GET("/seckill", func(c *gin.Context) {

        // 轻量级goroutine处理请求

        go func() {

            // 直接操作Redis库存

            if err := redisClient.Decr("stock").Err(); err != nil {

                c.JSON(http.StatusOK, gin.H{"result": "fail"})

                return

            }

            c.JSON(http.StatusOK, gin.H{"result": "success"})

        }()

    })

    router.Run(":8080")

}

性能数据：单机轻松支撑 10 万 QPS，p99 延迟 < 5ms。

Java 实现（Spring Boot + 虚拟线程） ：

@RestController

public class SeckillController {

    @GetMapping("/seckill")

    public CompletableFuture<ResponseEntity<String>> seckill() {

        return CompletableFuture.supplyAsync(() -> {

            // 虚拟线程处理IO操作

            if (redisTemplate.opsForValue().decrement("stock") < 0) {

                return ResponseEntity.ok("fail");

            }

            return ResponseEntity.ok("success");

        }, Executors.newVirtualThreadPerTaskExecutor());

    }

}

性能数据：Java 21 虚拟线程让 IO 密集型场景吞吐量提升 7 倍，p99 延迟从 165ms 降至 23ms。

核心差异：

• Go：天生适合高并发，Goroutine 调度和原生 Redis 操作无额外开销。


• Java：依赖 JVM 调优，虚拟线程虽大幅提升性能，但需配合线程池和异步框架。

场景 2：智能运维平台（云原生领域）

Go 实现（Ollama + gRPC） ：

func main() {

    // 启动gRPC服务处理AI推理请求

    server := grpc.NewServer()

    pb.RegisterAIAnalysisServer(server, &AIHandler{})

    go func() {

        if err := server.Serve(lis); err != nil {

            log.Fatalf("Server exited with error: %v", err)

        }

    }()

    

    // 采集节点数据（百万级设备）

    for i := 0; i < 1000000; i++ {

        go func(nodeID int) {

            for {

                data := collectMetrics(nodeID)

                client.Send(data) // 通过channel传递数据

            }

        }(i)

    }

}

优势：轻量级 Goroutine 高效处理设备数据采集，gRPC 接口响应速度比 REST 快 30%。

Java 实现（Spring Cloud + Kafka） ：

@Service

public class MonitorService {

    @Autowired

    private KafkaTemplate<String, String> kafkaTemplate;



    public void collectMetrics(int nodeID) {

        ScheduledExecutorService executor = Executors.newScheduledThreadPool(100);

        executor.scheduleAtFixedRate(() -> {

            String data =采集数据(nodeID);

            kafkaTemplate.send("metrics-topic", data);

        }, 0, 1, TimeUnit.SECONDS);

    }

}

挑战：传统线程池在百万级设备下内存占用飙升，需配合 Kafka 分区和 Consumer Gr0up 优化。

核心差异：

• Go：云原生基因，从采集到 AI 推理全链路高效协同。


• Java：生态依赖强，需整合 Spring Cloud、Kafka 等组件，部署复杂度高。

场景 3：企业 ERP 系统（传统行业）

Java 实现（Spring + Hibernate） ：

@Entity

@Table(name = "orders")

public class Order {

    @Id

    @GeneratedValue(strategy = GenerationType.IDENTITY)

    private Long id;



    @ManyToOne

    @JoinColumn(name = "user_id")

    private User user;



    // 复杂业务逻辑注解

    @PrePersist

    public void validateOrder() {

        if (totalAmount < 0) {

            throw new BusinessException("金额不能为负数");

        }

    }

}

优势：Spring 的事务管理和 Hibernate 的 ORM 完美支持复杂业务逻辑，代码可读性高。

Go 实现（GORM + 接口组合） ：

type Order struct {

    ID        uint   `gorm:"primaryKey"`

    UserID    uint

    Total     float64

}



func (o *Order) Validate() error {

    if o.Total < 0 {

        return errors.New("金额不能为负数")

    }

    return nil

}



func CreateOrder(ctx context.Context, order Order) error {

    if err := order.Validate(); err != nil {

        return err

    }

    return db.Create(&order).Error

}

挑战：需手动实现事务和复杂校验逻辑，代码量比 Java 多 20%。

核心差异：

• Java：企业级成熟度，框架直接支持事务、权限、审计等功能。


• Go：灵活性高，但需手动实现大量基础功能，适合轻量级业务。

二、技术本质：为什么 Go 在某些场景碾压 Java？

从 并发模型、内存管理、性能调优 三个维度，深挖两者的底层差异。

1. 并发模型：Goroutine vs 线程 / 虚拟线程

Go 的 Goroutine：

• 轻量级：每个 Goroutine 仅需 2KB 栈空间，可轻松创建百万级并发。


• 调度高效：基于 GMP 模型，避免内核级上下文切换，IO 阻塞时自动释放线程。

Java 的虚拟线程（Java 21+） ：

• 革命性改进：每个虚拟线程仅需几百字节内存，IO 密集型场景吞吐量提升 7 倍。


• 兼容传统代码：无需修改业务逻辑，直接将new Thread()替换为Thread.startVirtualThread()。

性能对比：

• HTTP 服务：Go 的 Gin 框架单机 QPS 可达 5 万，Java 21 虚拟线程 + Netty 可达 3 万。


• 消息处理：Go 的 Kafka 消费者单节点处理速度比 Java 快 40%。

2. 内存管理：逃逸分析 vs 分代 GC

Go 的逃逸分析：

• 栈优先分配：对象若未逃逸出函数，直接在栈上分配，减少 GC 压力。


• 零拷贝优化：io.Reader接口直接操作底层缓冲区，避免内存复制。

Java 的分代 GC：

• 成熟但复杂：新生代采用复制算法，老年代采用标记 - 压缩，需通过-XX:G1HeapRegionSize等参数调优。


• 内存占用高：同等业务逻辑下，Java 堆内存通常是 Go 的 2-3 倍。

典型案例：

某金融公司用 Go 重构风控系统后，内存占用从 8GB 降至 3GB，GC 停顿时间从 200ms 缩短至 10ms。

3. 性能调优：静态编译 vs JIT 编译

Go 的静态编译：

• 启动快：编译后的二进制文件直接运行，无需预热 JVM。


• 可预测性强：性能表现稳定，适合对延迟敏感的场景（如高频交易）。

Java 的 JIT 编译：

• 动态优化：运行时将热点代码编译为机器码，长期运行后性能可能反超 Go。


• 依赖调优经验：需通过-XX:CompileThreshold等参数平衡启动时间和运行效率。

实测数据：

• 启动时间：Go 的 HTTP 服务启动仅需 20ms，Java Spring Boot 需 500ms。


• 长期运行：持续 24 小时压测，Java 的吞吐量可能比 Go 高 10%（JIT 优化后）。

三、行业趋势：Go 在蚕食 Java 市场，但 Java 不会轻易退场

从 市场数据、生态扩展、技术演进 三个维度，分析两者的未来走向。

1. 市场数据：Go 在高速增长，Java 仍占主导

• 份额变化：Go 在 TIOBE 排行榜中从 2020 年的第 13 位升至 2025 年的第 7 位，市场份额突破 3%。


• 薪资对比：Go 开发者平均薪资比 Java 高 20%，但 Java 岗位数量仍是 Go 的 5 倍。

典型案例：

• 字节跳动：核心推荐系统用 Go 重构，QPS 提升 3 倍，成本降低 60%。


• 招商银行：核心交易系统仍用 Java，但微服务网关和监控平台全面转向 Go。

2. 生态扩展：Go 拥抱 AI，Java 深耕企业级

Go 的 AI 集成：

• 工具链完善：通过 Ollama 框架可直接调用 LLM 模型，实现智能运维告警。


• 性能优势：Go 的推理服务延迟比 Python 低 80%，适合边缘计算场景。

Java 的企业级护城河：

• 大数据生态：Hadoop、Spark、Flink 等框架仍深度依赖 Java。


• 移动端统治力：尽管 Kotlin 流行，Android 系统底层和核心应用仍用 Java 开发。

3. 技术演进：Go 和 Java 都在进化

Go 的发展方向：

• 泛型完善：Go 1.18 + 支持泛型，减少重复代码（如PrintSlice函数可适配任意类型）。


• WebAssembly 集成：计划将 Goroutine 编译为 Wasm，实现浏览器端高并发。

Java 的反击：

• Project Loom：虚拟线程已转正，未来将支持更细粒度的并发控制。


• Project Valhalla：引入值类型，减少对象装箱拆箱开销，提升性能 15%。

四、选型建议：Java 开发者该如何应对？

作为八年 Java 老兵，我的 技术选型原则 是：用最合适的工具解决问题，而非陷入语言宗教战争。

1. 优先选 Go 的场景

• 云原生基础设施：API 网关、服务网格、CI/CD 工具链（如 Kubernetes 用 Go 开发）。


• 高并发实时系统：IM 聊天、金融交易、IoT 数据采集（单机 QPS 需求 > 1 万）。


• AI 推理服务：边缘计算节点、实时推荐系统（需低延迟和高吞吐量）。

2. 优先选 Java 的场景

• 复杂企业级系统：ERP、CRM、银行核心业务（需事务、权限、审计等功能）。


• Android 开发：系统级应用和性能敏感模块（如相机、传感器驱动）。


• 大数据处理：离线分析、机器学习训练（Hadoop/Spark 生态成熟）。

3. 混合架构：Go 和 Java 共存的最佳实践

• API 网关用 Go：处理高并发请求，转发到 Java 微服务。


• AI 推理用 Go：部署轻量级模型，结果通过 gRPC 返回给 Java 业务层。


• 数据存储用 Java：复杂查询和事务管理仍由 Java 服务处理。

代码示例：Go 调用 Java 微服务

// Go客户端

conn, err := grpc.Dial("java-service:8080", grpc.WithInsecure())

if err != nil {

    log.Fatalf("连接失败: %v", err)

}

defer conn.Close()



client := pb.NewJavaServiceClient(conn)

resp, err := client.ProcessData(context.Background(), &pb.DataRequest{Data: "test"})

if err != nil {

    log.Fatalf("调用失败: %v", err)

}

fmt.Println("Java服务返回:", resp.Result)

// Java服务端

@GrpcService

public class JavaServiceImpl extends JavaServiceGrpc.JavaServiceImplBase {

    @Override

    public void processData(DataRequest request, StreamObserver<DataResponse> responseObserver) {

        String result =复杂业务逻辑(request.getData());

        responseObserver.onNext(DataResponse.newBuilder().setResult(result).build());

        responseObserver.onCompleted();

    }

}

五、总结：焦虑源于未知，成长来自行动

回到开篇的问题：Go 会取代 Java 吗？  我的答案是：短期内不会，但长期会形成互补格局。

• Java 的不可替代性：企业级成熟度、Android 生态、大数据框架，这些优势难以撼动。


• Go 的不可阻挡性：云原生、高并发、AI 集成，这些领域 Go 正在建立新标准。

作为开发者，与其焦虑语言之争，不如：

最后分享一个真实案例：某电商公司将支付核心用 Java 保留，抢购服务用 Go 重构，大促期间 QPS 从 5 万提升到 50 万，系统总成本降低 40%。这说明，语言只是工具，业务价值才是终极目标。

最近，我在我们前端团队里推行了一个“强制性”的规定：所有新项目，必须使用pnpm作为包管理工具；所有老项目，必须在两个月内，逐步迁移到pnpm。

这个决定，一开始在团队里是有阻力的。

有同事问：“老大，npm用得好好的，为啥非要换啊？我们都习惯了。”

也有同事说：“yarn不也挺快的吗？再换个pnpm，是不是在瞎折腾？”

我理解大家的疑问。但我之所以要用“强制”这个词，是因为在我看来，在2025年的今天，继续使用npm或yarn，就像是明明有高铁可以坐，你却非要坚持坐绿皮火车一样，不是不行，而是没必要。

这篇文章，我就想把我的理由掰开揉碎了，讲给大家听。

npm和yarn的“原罪”：那个又大又慢的node_modules

在聊pnpm的好处之前，我们得先搞明白，npm和yarn（特指yarn v1）到底有什么问题。

它们最大的问题，都源于一个东西——扁平化的node_modules。

你可能觉得奇怪，“扁平化”不是为了解决npm v2时代的“依赖地狱”问题吗？是的，它解决了老问题，但又带来了新问题：

1. “幽灵依赖”（Phantom Dependencies）

这是我最不能忍受的一个问题。

举个例子：你的项目只安装了A包（npm install A）。但是A包自己依赖了B包。因为是扁平化结构，B包也会被提升到node_modules的根目录。

结果就是，你在你的代码里，明明没有在package.json里声明过B，但你却可以import B from 'B'，而且代码还能正常运行！

这就是“幽灵依赖”。它像一个幽灵，让你的项目依赖关系变得混乱不堪。万一有一天，A包升级了，不再依赖B了，你的项目就会在某个意想不到的地方突然崩溃，而你甚至都不知道B是从哪来的。

2. 磁盘空间的巨大浪费

如果你电脑上有10个项目，这10个项目都依赖了lodash，那么在npm/yarn的模式下，你的磁盘上就会实实在在地存着10份一模一样的lodash代码。

对于我们这些天天要开好几个项目的前端来说，电脑的存储空间就这么被日积月累地消耗掉了。

3. 安装速度的瓶颈

虽然npm和yarn都有缓存机制，但在安装依赖时，它们仍然需要做大量的I/O操作，去复制、移动那些文件。当项目越来越大，node_modules动辄上G的时候，那个安装速度，真的让人等到心焦。

pnpm是怎么解决这些问题的？——“符号链接”

好了，现在主角pnpm登场。pnpm的全称是“performant npm”，意为“高性能的npm”。它解决上面所有问题的核心武器，就两个字：链接。

pnpm没有采用扁平化的node_modules结构，而是创建了一个嵌套的、有严格依赖关系的结构。

1. 彻底告别“幽灵依赖”

在pnpm的node_modules里，你只会看到你在package.json里明确声明的那些依赖。

你项目里依赖的A包，它自己所依赖的B包，会被存放在node_modules/.pnpm/这个特殊的目录里，然后通过 符号链接（Symbolic Link） 的方式，链接到A包的node_modules里。

这意味着，在你的项目代码里，你根本访问不到B包。你想import B？对不起，直接报错。这就从结构上保证了，你的项目依赖关系是绝对可靠和纯净的。

2. 磁盘空间的“终极节约”

pnpm会在你的电脑上创建一个“全局内容可寻址存储区”（content-addressable store），通常在用户主目录下的.pnpm-store里。

你电脑上所有项目的所有依赖，都只会在这个全局仓库里，实实在在地只存一份。

当你的项目需要lodash时，pnpm不会去复制一份lodash到你的node_modules里，而是通过 硬链接（Hard Link） 的方式，从全局仓库链接一份过来。硬链接几乎不占用磁盘空间。

这意味着，就算你有100个项目都用了lodash，它在你的硬盘上也只占一份的空间。这个特性，对于磁盘空间紧张的同学来说，简直是福音。

3. 极速的安装体验

因为大部分依赖都是通过“链接”的方式实现的，而不是“复制”，所以pnpm在安装依赖时，大大减少了磁盘I/O操作。

它的安装速度，尤其是在有缓存的情况下，或者在安装一个已经存在于全局仓库里的包时，几乎是“秒级”的。这种“飞一般”的感觉，一旦体验过，就再也回不去了。

为什么我要“强制”？

聊完了技术优势，再回到最初的问题：我为什么要“强制”推行？

因为包管理工具的统一，是前端工程化规范里最基础、也最重要的一环。

如果一个团队里，有人用npm，有人用yarn，有人用pnpm，那就会出现各种各样的问题：

• 不一致的lock文件：package-lock.json, yarn.lock, pnpm-lock.yaml互相冲突，导致不同成员安装的依赖版本可能不完全一致，引发“在我电脑上是好的”这种经典问题。


• 不一致的依赖结构：用npm的同事，可能会不小心写出依赖“幽灵依赖”的代码，而用pnpm的同事拉下来，代码直接就跑不起来了。

在一个团队里，工具的统一，是为了保证环境的一致性和协作的顺畅。而pnpm，在我看来，就是当前这个时代下，包管理工具的“最优解”。

所以，这个“强制”，不是为了搞独裁，而是为了从根本上提升我们整个团队的开发效率和项目的长期稳定性。

最后的经验

从npm到yarn，再到pnpm，前端的包管理工具一直在进化。

pnpm用一种更先进、更合理的机制，解决了过去遗留下的种种问题。它带来的不仅仅是速度的提升，更是一种对“依赖关系纯净性”和“工程化严谨性”的保障。

我知道，改变一个人的习惯很难。但作为团队的负责人，我有责任去选择一条更高效、更正确的路，然后带领大家一起走下去。

如果你还没用过pnpm，我强烈建议你花十分钟，在你的新项目里试一试🙂。

多线程爬虫的使用主要是为了提高网络爬虫的效率和性能。以下是几个关键原因：

多线程爬取网站案例

# -*- coding: UTF-8 -*-

'''

@Project ：网络爬虫 

@File    ：11-多线程爬虫案例.py

@IDE     ：PyCharm 

@Author  ：慕逸

@Date    ：09/11/2024 19:54 

'''





# https://www.doutupk.com/search?type=photo&more=1&keyword=%E9%9D%93%E4%BB%94&page=3



import requests

from urllib import request

from lxml import etree

import threading

from queue import Queue

import winsound





class Producer(threading.Thread):

    headers = {

        'user-agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36'

    }



    def __init__(self, page_queue, img_queue):

        super().__init__()

        self.page_queue = page_queue

        self.img_queue = img_queue



    def run(self):

        while True:

            if self.page_queue.empty():

                break

            url = self.page_queue.get()

            self.parse_page(url)



    def parse_page(self, url):

        response = requests.get(url, headers=self.headers)

        text = response.text

        # print(text)

        html = etree.HTML(text)

        imgs = html.xpath("//div[@class='pic-content text-center']//img[@class!='gif']")

        img_names = html.xpath(

            "//div[@class='pic-content text-center']//img[@class!='gif']/following-sibling::p/text()")



        for img, img_name in zip(imgs, img_names):

            img_url = img.get('data-original')

            # request.urlretrieve(img_url, 'E:/Study/code/Python/图片爬取/斗图啦/{}'.format(img_name) + str(random.randint(1, 10000)) + '.jpg')

            # print(img_name + "-下载完成~~" + img_url)

            self.img_queue.put((img_url, img_name))





class Consumer(threading.Thread):

    def __init__(self, page_queue, img_queue):

        super().__init__()

        self.page_queue = page_queue

        self.img_queue = img_queue



    def run(self):

        while True:

            if self.img_queue.empty() and self.page_queue.empty():

                break

            img = self.img_queue.get()

            img_url, file_name = img

            file_name = file_name.replace('.','').replace('?','')

            request.urlretrieve(img_url, 'E:/Study/code/Python/图片爬取/斗图啦/{}.jpg'.format(file_name))

            print(file_name + "-下载完成~~" + img_url)





def main():

    winsound.Beep(1500, 500)

    page_queue = Queue(100)

    img_queue = Queue(500)



    for i in range(1, 18):

        url = "https://www.doutupk.com/search?type=photo&more=1&keyword=%E9%9D%93%E4%BB%94&page={}".format(i)

        # parse_page(url)

        page_queue.put(url)

        # break



    # 创建5个线程

    for i in range(5):

        t = Producer(page_queue, img_queue)

        t.start()



    for i in range(5):

        t = Consumer(page_queue, img_queue)

        t.start()





if __name__ == '__main__':

    main()

    winsound.Beep(1000, 500)

• 生产者类负责从队列中获取页面 URL，解析页面并提取图片信息，然后将图片信息放入图片队列中。


• 消费者类负责从图片队列中获取图片信息，下载图片并保存到本地。

前言

最近在研究 Tauri 2.0 如何自动更新，跟着官网教程来了一遍，发现并不顺利，踩了很多坑，不过好在最后终于走通了，今天整理一下供大家参考。

第一步

自动更新利用的是 Tauri 的 Updater 组件，所以这里需要安装一下：

PNPM 执行这个（笔者用的 PNPM）：

pnpm tauri add updater

NPM 执行这个：

npm run tauri add updater

接着在 /src-tauri/tauri.conf.json 文件中添加以下配置：

{

  "bundle": {

    "createUpdaterArtifacts": true

  },

  "plugins": {

    "updater": {

      "pubkey": "你的公钥",

      "endpoints": ["https://releases.myapp.com/latest.json"]

    }

  }

}

其中：

• createUpdaterArtifacts 为是否创建更新包，设置为 true 即可。根据官网介绍，未来发布的 V3 版本将无需设置。


• pubkey 是公钥，用于和私钥匹配（私钥在开发环境配置，并在打包时自动携带）。但此时我们还没有，所以需要生成一下，执行以下命令生成密钥对：
  
  

  PNPM 执行这个：

  
  

  pnpm tauri signer generate -w ~/.tauri/myapp.key
  
  

  
  

  NPM 执行这个：

  
  

  npm run tauri signer generate -- -w ~/.tauri/myapp.key
  
  

  
  

  执行时会要求输入一个密码用来保护密钥，也可以直接按回车跳过，建议还是输入一个：

  
  

  

  
  

  输入（或跳过）之后，将会继续生成，生成之后进入刚才我们指定的目录 ~/.tauri：

  
  

  

  
  

  打开公钥 myapp.key.pub 然后将上面的 pubkey 替换掉。

  
  

  私钥的话，打开 myapp.key 然后执行以下方法设置到环境变量：

  
  

  macOS 和 Linux 执行这个（笔者是 macOS）：

  
  

  export TAURI_SIGNING_PRIVATE_KEY="你的私钥"
  
  export TAURI_SIGNING_PRIVATE_KEY_PASSWORD="你刚才输入的密码，没有就不用设置。"
  
  

  
  

  Windows 使用 Powershell 执行这个:

  
  

  $env:TAURI_SIGNING_PRIVATE_KEY="你的私钥"
  
  $env:TAURI_SIGNING_PRIVATE_KEY_PASSWORD="你刚才输入的密码，没有就不用设置。"
  
  

  
  


• endpoints 用于 Tauri 检查更新，是一个数组，所以可以设置多个，将会依次尝试可用的 URL，URL 指向放置在服务器的用于存储版本信息的 JSON 文件（也可以使用 API 的形式，这里不介绍了），格式如下：
  
  

  {
  
    "version": "1.0.1",
  
    "notes": "更新说明",
  
    "pub_date": "2025-05-21T03:29:28.626Z",
  
    "platforms": {
  
      "darwin-aarch64": {
  
        "signature": "dW50cnVzdGVkIGNvbW1lbnQ6IHNpZ25hdHVyZSBmcm9tIHRhdXJpIHNlY3JldCBrZXkKUlVTU0xJb2k1U3J6ZVFoUWo3R2lMTm5EdzhoNUZTKzdsY0g1NktOOTFNL2RMM0JVVVl4b0k3bFB0MkhyL3pKOHRYZ0x0RVdUYzdyWVJvNDBtRDM0OGtZa2d0RWl0VTBqSndrPQp0cnVzdGVkIGNvbW1lbnQ6IHRpbWVzdGFtcDoxNzQ3Nzk1MTY5CWZpbGU6bXktdGF1cmktYXBwLmFwcC50YXIuZ3oKS1N0UDl5MHRteUd0RHJ6anlSMXBSWmNJUlNKb1pYTDFvK2EvUjArTlBpbXVGN3pnQlA0THhhVUd4S3JrZy9lNHBNbWVSU2VoaCswN25xNEFPcmtUQnc9PQo=",
  
        "url": "macOS 包下载地址"
  
      }
  
    }
  
  }
  
  

  
  

  将此 JSON 文件放置在服务器，然后将上面的 endpoints 数组里的地址替换为这个 JSON 的真实地址。

  
  

  其中：

  
  
  
  
  • version 是版本号，升级时需要大于当前用户使用的版本。
  
  
  • notes 是更新说明，可以向用户说明本次更新的内容。
  
  
  • pub_date 是更新日期，非必填。
  
  
  • platform 是更新的平台，这里我以 macOS 为例，Windows 同理。
  
  
  • signature 是每次打包后的签名，所以每次都不一样，macOS 默认在 /src-tauri/target/release/bundle/macos/my-tauri-app.app.tar.gz.sig 这个位置，将这个文件打开，复制里面的内容替换即可。
  
  
  
  

第二步

配置好以后，就可以在应用内调用 check 方法进行更新了，比如在用户每次应用启动后。以下是从检查更新到更新完成的全流程的必要代码：

import { check } from '@tauri-apps/plugin-updater'

import { relaunch } from '@tauri-apps/plugin-process'



const fetchVersion = async () => {

  const update = await check()



  if (update) {

    console.log(`found update ${update.version} from ${update.date} with notes ${update.body}`)

    let downloaded = 0

    let contentLength = 0

    // 也可以分开调用 update.download() 和 update.install()

    await update.downloadAndInstall(event => {

      switch (event.event) {

        case 'Started':

          contentLength = event.data.contentLength

          console.log(`started downloading ${event.data.contentLength} bytes`)

          break

        case 'Progress':

          downloaded += event.data.chunkLength

          console.log(`downloaded ${downloaded} from ${contentLength}`)

          break

        case 'Finished':

          console.log('download finished')

          break

      }

    })



    console.log('update installed')

    // 此处 relaunch 前最好询问用户

    await relaunch()

  }

}

代码已经很简洁了，相信大家能看懂，但还是简单说一下：

首先调用 check 方法。检查之后，check 方法会返回一个 update 对象，如果检查到有更新，该对象会包含上面的版本更新信息，也包含一个 downloadAndInstall 方法。

执行 downloadAndInstall 方法，该方法执行完之后就代表安装成功了，会在下次启动时更新为新版本。当然也可以立即生效，只需要调用 relaunch 方法重启应用即可，但重启前最好提醒用户。

源码（经测试已经成功实现自动更新）已经上传到 Github：github.com/reallimengz…

背景

最近公司对代码质量抓得很严, 出台了一系列组合拳:

今天先说说，在本地使用git提交代码时进行代码质量检查如何实现。现在进入主题

Step1 配置ESLint校验规则

在这一步，踩了一个大坑。现在安装ESLint, 安装的都是ESLint v9.x版本，ESLint v9+的配置文件与之前不太一样了。不管是问大模型，还是上网搜，搜出来的ESLint安装配置方式90%以上都是ESLint V8及以下版本的配置方法。按照那种方式配，会吃很多瘪。

能看懂的，简单一点的报错比如说：

• .eslintignore文件不再被支持，应该在 eslint.config.js 或 eslint.config.ts 配置文件中，使用 ignores 属性来指定哪些文件或目录需要被忽略。
  (node:13688) ESLintIgnoreWarning: The ".eslintignore" file is no longer supported. Switch to using the "ignores" property in "eslint.config.js": https://eslint.org/docs/latest/use/configure/migration-guide#ignoring-files (Use node --trace-warnings ... to show where the warning was created) Oops! Something went wrong! :( ESLint: 9.25.1)，


• 改成ignores又报错， 对象字面量只能指定已知属性，并且“ignores”不在类型“ESLintConfig”中，被大模型忽悠了一回。在 ESLint 9.x 中，应该使用 ignorePatterns 来指定要忽略的文件或文件夹，而不是 ignores。


• jiti包版本不匹配, 需要升级
  Oops! Something went wrong! :( ESLint: 9.25.1 Error: You are using an outdated version of the 'jiti' library. Please update to the latest version of 'jiti' to ensure compatibility and access to the latest features.


• 未安装eslint-define-config模块
  Oops! Something went wrong! :( ESLint: 9.25.1 Error: Cannot find module 'eslint-define-config'

不太容易看懂的报错比如说 ESLint 没有找到适用于文件 src/main.ts 的配置规则。0:0 warning File ignored because no matching configuration was supplied ， 按照大模型的提示，逐一检查了ESLint 配置文件的路径是否正确，确保 root: true 配置生效; TypeScript 和 Vue 插件及解析器配置是否正确; ignorePatterns 是否误忽略了 src 文件夹; 检查 tsconfig.json 中的 include 配置; 手动检查文件是否被 ESLint 正确解析

pnpm eslint --config ./eslint.config.ts src/main.ts

忙活了一圈，未能解决问题。大模型排查技术工具最新版本的故障问题能力偏弱。无奈只能在网上搜，一篇一篇的看与试错。最终验证通过是方案是采用@eslint/config生成eslint v9版本的配置文件。

pnpm create @eslint/config

做7个选择（每个选项的含义一眼就能看懂）之后，就能妥妥地生成eslint配置文件。

Step2 配置Husky

这一步比较简单，虽然Husky最新版本的配置方法与先前的版本不一样了。但新版本的配置比老版本的要简单一些。

✅ 1. 安装Husky v9+版本

pnpm add -D husky

✅ 2. Husky v9+版本初始化

npx husky init

这会自动：

• 创建 .husky/ 目录


• 在.husky/下添加 pre-commit hook 示例


• 在package.json中添加 "prepare": "husky install" 脚本

这一步有个小坑，就是如果npx husky init第一次因为某种原因运行失败,第二次再运行，不会生成.husky目录。解决方法也很简单粗暴，卸载husky重新安装。

✅ 3. 在package.json配置检查指令

{

  "scripts": {

    "lint": "run-s lint:*",

    "lint:eslint": "eslint src/**/*.{ts,tsx,vue}  --debug --cache",

    "lint:prettier": "prettier --check ./",

    "lint:style": "stylelint \"src/**/*.{vue,css,less}\" --fix",

  },

}

✅ 4. 修改 .husky/pre-commit hook

# 检查指令

pnpm lint

Step3 配置ESLint增量检测

为什么要配置增量检测呢，原因有两点：

那么如何做增量检查呢？最质朴的思路就是利用git能监测暂存区代码变更的能力，然后利用ESlint对变更的文件执行代码质量检查。这里有两处要注意一下，一是检查暂存区变更的文件，要过滤掉删除的文件,只检查新增，修改，重命名,复制的文件。另外，当没有匹配类型的文件时，files=$(git diff --cached --name-only --diff-filter=AMRC | grep -E '\.(ts|tsx|vue)$')会抛出一个exit 1的异常，造成改了(ts|tsx|vue)之外的文件不能正常提交，所以要在后面加一个|| true进行兜底。

#!/bin/bash

# set -e

# set -x

trap 'echo "Error at line $LINENO"; exit 1' ERR



# 注意这里加了 || true

files=$(git diff --cached --name-only --diff-filter=AMRC | grep -E '\.(ts|tsx|vue)$' || true)



if [ -z "$files" ]; then

  echo "No changed ts/tsx/vue files to check."

  exit 0

fi



echo "Running ESLint on the following files:"

echo "$files"



# 用 xargs -r 只有在有输入时才执行

echo "$files" | xargs -r npx eslint



echo "All files passed ESLint."

exit 0

Step4 测试效果

修改 src 下的某个 main.ts 文件，故意触发代码质量问题，然后提交。

• 情形1 通过命令行提交，eslint校验未通过，阻断提交，且是增量校验。

git add . && git commit -m "测试"

• 情形2 通过UI界面提交，成功阻断提交
  

至此大功告成，结果令人满意，如果你的项目也需要实现这样的功能的话，拿走不谢。

后记

业务背景是这样的：gitlab上有个填写公司的仓库，有个提交代码的仓库，现在要将提交代码的仓库的代码变更记录，添加到填写工时的议题评论列表中，只要按照 feat: 跨项目提交测试 #194(#194是填写工时的议题id)这样的格式填写提交语，就能实现在评论列表添加代码变更链接的效果。

在.husky目录下添加prepare-commit-msg文件，内容如下：

#!/bin/sh

. "$(dirname "$0")/_/husky.sh"



# 仅当手动写 commit message 时执行

if [ "$2" = "merge" ] || [ "$2" = "squash" ]; then

  exit 0

fi



file="$1"

msg=$(cat "$file")



# 查找是否包含 #数字 格式的 Issue 编号

issue_number=$(echo "$msg" | grep -Eo '#[0-9]+' | head -n1 | sed 's/#//')



if [ -n "$issue_number" ]; then

  # 自定义项目路径

  project_path="research-and-development/algorithm/项目名"



  # 如果已经包含路径，则不重复添加

  echo "$msg" | grep -q "$project_path" && exit 0



  echo "" >>"$file"

  echo "Related to $project_path#$issue_number" >>"$file"

fi

需要注意的是，你使用的gitlab版本必须大于v15,才支持跨项目议题关联功能

最近，和往常一样在刷 GitHub Trending 热榜时，突然看到又一个开源项目冲上了 Trending 榜单。

一天之内就狂揽数千 star，仅仅用两三天时间，star 数就迅速破万，增长曲线都快干垂直了！

出于好奇，点进去看了看。

好家伙，这居然还是小米开源的项目，相信不少小伙伴也刷到了。

这个项目名为：ha_xiaomi_home。

全称：Xiaomi Home Integration for Home Assistant。

原来这就是小米开源的 Home Assistant 米家集成，一个由小米官方提供支持的 Home Assistant 集成组件，它可以让用户在 Home Assistant 平台中使用和管理小米 IoT 智能设备。

Home Assistant 大家知道，这是一款开源的家庭自动化智能家居平台，以其开放性和兼容性著称，其允许用户将家中的智能设备集成到一个统一的系统中进行管理和控制，同时支持多种协议和平台。

通过 Home Assistant，用户可以轻松地实现智能家居的自动化控制，如智能灯光、智能安防、智能温控等，所以是不少智能家居爱好者的选择。

另外通过安装集成（Integration），用户可以在 Home Assistant 上实现家居设备的自动化场景创建，并且还提供了丰富的自定义功能，所以一直比较受 DIY 爱好者们的喜爱。

大家知道，小米在智能家居领域的战略布局一直还挺大的，IoT 平台的连接设备更是数以亿记，大到各种家电、电器，小到各种摄像头、灯光、开关、传感器，产品面铺得非常广。

那这次小米开源的这个所谓的米家集成组件，讲白了就是给 Home Assistant 提供官方角度的支持。

而这对于很多喜欢折腾智能家居或者 IoT 物联网设备的小伙伴来说，无疑也算是一个不错的消息。

ha_xiaomi_home 的安装方法有好几种，包括直接 clone 安装，借助 HACS 安装，或者通过 Samba 或 FTPS 来手动安装等。

但是官方是推荐直接使用 git clone 命令来下载并安装。

cd config

git clone https://github.com/XiaoMi/ha_xiaomi_home.git

cd ha_xiaomi_home

./install.sh /config

原因是，这样一来当用户想要更新至特定版本时，只需要切换相应 Tag 即可，这样会比较方便。

比如，想要更新米家集成版本至 v1.0.0，只需要如下操作即可。

cd config/ha_xiaomi_home

git checkout v1.0.0

./install.sh /config

安装完成之后就可以去 Home Assistant 的设置里面去添加集成了，然后使用小米账号登录即可。

其实在这次小米官方推出 Home Assistant 米家集成之前，市面上也有一些第三方的米家设备集成，但是多多少少会有一些不完美的地方，典型的比如设备状态响应延时，所以导致体验并不是最佳。

与这些第三方集成相比，小米这次新推出的官方米家集成无论是性能还是安全性都可以更期待一下。

如官方所言，Home Assistant 米家集成提供了官方的 OAuth 2.0 登录方式，并不会在 Home Assistant 中保存用户的账号密码，同时账号密码也不再需提供给第三方，因此也就避免了账号密码泄露的风险。

但是这里面仍然有一个问题需要注意，项目官方也说得很明确：虽说 Home Assistant 米家集成提供了 OAuth 的登录方式，但由于 Home Assistant 平台的限制，登录成功后，用户的小米用户信息（包括设备信息、证书、 token 等）会明文保存在 Home Assistant 的配置文件中。因此用户需要保管好自己的 Home Assistant 配置文件，确保不要泄露。

这个项目开源之后，在网上还是相当受欢迎的，当然讨论的声音也有很多。
小米作为一家商业公司，既然专门搞了这样一个开源项目来做 HA 米家集成，这对于他们来说不管是商业还是产品，肯定都是有利的。

不过话说回来，有了这样一个由官方推出的开源集成组件，不论是用户体验还是可玩性都会有所提升，这对于用户来说也未尝不是一件好事。

那关于这次小米官方开源的 Home Assistant 米家集成项目，大家怎么看呢？

注：本文在GitHub开源仓库「编程之路」 github.com/rd2coding/R… 中已经收录，里面有我整理的6大编程方向(岗位)的自学路线+知识点大梳理、面试考点、我的简历、几本硬核pdf笔记，以及程序员生活和感悟，欢迎star。

牛马终究还是回到了草原

大家好呀，今天开始继续更新文章了，最近一个月因为换了城市，调整状态花了不少时间，现在才有些动力继续更新，今天来聊聊最近一年多的经历

1.回二线城市

23年12月的时候，我从北京阿里离职了，回到离家近的武汉，拿了一个国企的offer，也是在那家国企待了一年多的时间。

至于为什么会选择回武汉，主要觉得在一线城市买不起房，而且长期在外离家远，漂泊感太重，还不如早点回二线城市定居下来，免得以后年龄大了更不好回来。所以，当时看武汉的机会主要找稳定的工作，除了国企offer，还拿过高校，以及其他偏稳定的公司offer。综合考虑后，才选的国企

回来之后没到两月，就有些后悔了。虽然回来之前做好了心理预期，工资会降低，只是国企的工资也低的过于少了吧，开始几个月工资只有原来的零头。而且，呆了一段时间后发现，这个国企在北京才是研发中心，武汉这边作为分中心，只是北京的“内包”而已。

项目经理都是在北京，很多还都是校招进去工作才两三年的，就让管武汉这边几个人的工作。这些人也没啥管理经验，就只是不停给底下人施压。而且经常搞的操作就是，项目都是有时间要求的，开始的时候不拉人进来干活，等到时间比较紧的时候，才拉人进来，这就导致武汉的人收到任务时，都是重要且紧急的工作。又或者正常工作日没安排活，等到要放假，或者下班之前，才给安排活，让自行加班完成，故意恶心人

2.上着北京的班，拿着武汉的工资

这个事在24年的时候，已经发过吐槽了，就发张截图看看

3.成长的焦虑

我在北京的时候，除了阿里，之前也呆过一家互联网公司。裁员是比较常见的事情，虽然我还没被裁过。

国企这边虽然说相对比较稳定，但是自从我这批大概20个人入职后，感觉在走下坡路了，不仅福利变少，而且也变卷了，还传出后面也要搞末尾淘汰的事。我呆了一年的时候，感觉比在一线时更害怕，假如我在这里被裁了，或者呆满三年不续签了，可能很难再找到合适的工作了，自身成长和工作年限严重不匹配，想到这，我终于还是下了决定再去一线城市

找下家的经历并不顺利，国企的项目可以说就是玩具而已，完全拿不出手。只能拿之前阿里的项目去讲。有些一线互联网大厂，面试了好几轮，好不容易都过了。在焦急等待了数周后，最后给我说横向比较有更合适的了，就不考虑了。其实大家也都明白是因为啥原因不给发。

4.空窗期

经历了几个月的找工作经历后，终于是拿到上海一家公司offer，于是也就顺理成章准备跑路了。趁着中间有半个月的空闲时间，去西边青海和西藏游玩了一次。那边景点之间距离远，在携程上报跟团游就行，价钱不高，比较推荐去青海游玩，那的牛肉和羊肉非常新鲜，值得尝试，3天的时间，每天都能看不一样的风景。

5.上海

已经到上海快两个月，开始逐渐习惯天天下雨的节奏，现在下班还是比较早的，下班的时候还能见着落日，比较WLB，没有互联网大厂那么的卷，却也是有些压力的。下面是第一周下班时路上的照片

今天就写到这吧，下次有新鲜事再分享~

昨儿中午吃着饭，不知道为啥突然和同事聊起来AI发展的事儿了。虽然我们只是"🐂🐎"，但是不妨碍咱们坐井观天，瞎扯淡聊聊天。

他的主要观点是：现阶段的AI绝对无法取代程序员，大家有点过度恐慌了。AI是程序员的工具，就像从记事本升级到IDE一样。

我的主要观点是：AI一定会取代大量的程序员，尤其是初级程序员。后续程序员岗将在软件公司内的比重降低，取而代之的是产品、需求和算法岗。

诚然，他说的也有一定的道理，就目前AI发展的速度和质量来看，其实大家的确有点儿过度恐慌了。

AI的确在一定程度上替代的程序员的工作，但是大多内容仍然是程序员群体在产出，这个是不容否认的事实。

不过另一个不容否认的事实是，我们越来越依赖AI了。原来大家写代码一般都是啥不会了，就直接去网上搜。比如说js怎么截断从第2位到最后一位，想不起来了，搜一搜。

现在有了AI，一般的操作都是在上面写个注释，然后回车一下，AI会自动帮你补全代码，连搜的功夫都省了。

由此俺也big胆的预言一把，CSD*、掘*、百*这些资讯类，尤其是做程序员这个方向的资讯网站会越来越没落。

原因是：有了问题，但是没有了搜索。没有搜索就没有共享解决方案的必要，因为没人看。没人看所以不再有人分享，最后Over。

Ps：或许我被啪啪打脸呢？

之前的AI编码工具我就有在用，包括阿里的通义，百度的文心，或者是IDEA里面内嵌的编码助手，以及之前CodeGeex等等吧，确确实实是提高了效率的。

这个阶段其实重点提升的是搜索的效率，有问题直接问AI，AI直接给出答案。95%的答案都是正确的，不必再去网上费劲巴拉的找了。

后来更上一层楼，Claude2、3直接翻倍的提升了开发效率。我不必再实现了，我只需要阐述需求，AI会自动给出答案。我需要的是把内容Copy下来，然后整合进我的工程里面。

后面的工作就还是原来的老步骤了，测试一下，没啥问题的话就发版，提测了。

但是现在这个阶段又进步了，TREA2.0 SOLO出道直接整合了全流程，整个过程直接变成了"智能体"把控，不再需要我的干涉了。

我需要做的工作就是阐述清楚我的需求，然后让TREA去实现。这个过程中可能也就只需要我关注一下实现的方向不要有太大的偏差，及时纠正一下(但是到目前为止没遇到过需要纠正的情况)。

也就是说，现在AI已经从原来的片面生成代码，到后面的理解需求生成单文件代码，到现在生成工程化代码了。

而我们的角色也从一个砌墙工人，拿到了一把能自动打灰的铲子。

到后面变成一个小组长，拿着尺子和吊锤看他们盖的墙有没有问题。

到现在变成包工头看着手底下的工人一层层的盖起大楼。

但是！

你说工地上是工人多，还是组长多，还是包工头多？真的需要这么多包工头嘛？

什么是透明贴图

• 核心作用：像「镂空剪纸」一样控制物体哪些部位透明/不透明
  
  

  （想象：给树叶模型贴图，透明部分让树叶边缘自然消失而非方形边缘）



• 技术本质：一张 黑白图片（如 PNG 带透明通道），其中：
  
  
  
  
  • 黑色区域 → 模型对应位置 完全透明（消失）
  
  
  • 白色区域 → 模型 完全不透明（显示）
  
  
  • 灰色过渡 → 半透明效果（如玻璃边缘）
  
  
  
  

示例：游戏中的铁丝网、树叶、破碎特效等镂空物体常用此技术

常见问题与解决方案

技巧：透明贴图需搭配 基础颜色贴图（map）  使用，两者共同决定最终外观

实际应用场景

实践案例一

效果如图

实现思路

通过canvas绘制内容，canvasTexture用来转换为3d纹理

    const canvas = document.createElement('canvas'),

    ctx = canvas.getContext('2d');

    canvas.width = 64;

    canvas.height = 64;

    ctx.fillStyle = '#404040';

    ctx.fillRect(0, 0, 32, 32);

    ctx.fillStyle = '#808080';

    ctx.fillRect(32, 0, 32, 32);

    ctx.fillStyle = '#c0c0c0';

    ctx.fillRect(0, 32, 32, 32);

    ctx.fillStyle = '#f0f0f0';

    ctx.fillRect(32, 32, 32, 32);

    const texture = new THREE.CanvasTexture(canvas);

这里画布大小设置为64*64，被均匀分割为4份，并填充不同的颜色

接下来创建一个立方体，为其贴上透明度贴图alphaMap，设置transparent:true这很关键

const geo = new THREE.BoxGeometry(1, 1, 1);

const material = new THREE.MeshBasicMaterial({

    color: 'deepskyblue',

    alphaMap: texture, // 透明度贴图

    transparent: true,

    opacity: 1,

    side: THREE.DoubleSide

});

如果你尝试将transparent配置改为false, 你将看到如下效果

同样我们尝试修改canvas绘制时候的填充色，来验证黑白镂空情况

ctx.fillStyle = '#000';

ctx.fillRect(0, 0, 32, 32);

ctx.fillStyle = '#000';

ctx.fillRect(32, 0, 32, 32);

ctx.fillStyle = '#000';

ctx.fillRect(0, 32, 32, 32);

ctx.fillStyle = '#fff';

ctx.fillRect(32, 32, 32, 32);

如图所示，黑色消失，白色显示保留

总结本案例需要掌握的API

CanvasTexture

这是Texture的子类，它用于将动态绘制的 2D Canvas 内容（如图表、文字、实时数据）转换为 3D 纹理，使得HTML Canvas元素可以作为纹理映射到3d物体表面

它支持实时更新，默认needsUpdate为true

应用场景

• 动态数据可视化：将实时图表（如温度曲线）映射到 3D 面板。


• 文字标签：在 3D 物体表面显示可变文字（如玩家名称）。


• 程序化纹理：通过算法生成图案（如噪波、分形）。


• 交互式绘制：用户画布涂鸦实时投射到 3D 模型（如自定义 T 恤设计）。

性能优化

• 避免频繁更新：若非必要，减少 needsUpdate=true 的调用频率。


• 合理尺寸：Canvas 尺寸建议为 2 的幂（如 256×256, 512×512），兼容纹理映射。


• 复用 Canvas：对静态内容，复用已生成的纹理而非重新创建。


• 替代方案：静态图像用 TextureLoader，视频用 VideoTexture，以降低开销。

需要注意

• 跨域限制：若 Canvas 包含外部图片，需设置 crossOrigin="anonymous"。


• 清晰度问题：高缩放比例可能导致模糊，可通过 texture.anisotropy = renderer.capabilities.getMaxAnisotropy() 改善。


• 内存管理：不再使用的纹理调用 texture.dispose() 释放资源。

实践案例二

效果如图

实现思路

从图上可以看出，立方体每个面上有多个矩形小方块，每个方块都被赋予不同的颜色，创建grid方法来实现生产多个矩形小方块

const drawMethod = {};

drawMethod.grid = (ctx, canvas, opt={} ) => {

    opt.w = opt.w || 4;

    opt.h = opt.h || 4;

    opt.colors = opt.colors || ['#404040', '#808080', '#c0c0c0', '#f0f0f0']; 

    opt.colorI = opt.colorI || []; 

    let i = 0;

    const len = opt.w * opt.h,

    sizeW = canvas.width / opt.w, // 网格宽度

    sizeH = canvas.height / opt.h;  // 网格高度



    while(i<len) {

        const x = i % opt.w,

        y = Math.floor(i / opt.w);

        ctx.fillStyle = typeof opt.colorI[i] === 'number' ? opt.colors[opt.colorI[i]] : opt.colors[i % opt.colors.length];

        ctx.fillRect(x * sizeW, y * sizeH, sizeW, sizeH);

        i++;

    }

}

实现透明贴图

const canvas = document.createElement('canvas'),

ctx = canvas.getContext('2d');

canvas.width = 64;

canvas.height = 64;

const texture = new THREE.CanvasTexture(canvas);



const geo = new THREE.BoxGeometry(1, 1, 1);

const material = new THREE.MeshBasicMaterial({

    color: 'deepskyblue',

    alphaMap: texture,

    transparent: true,

    opacity: 1,

    side: THREE.DoubleSide

});

这里要注意，canvas上并未绘制任何内容，我们将在loop循环中调用grid方法进行绘制

let frame = 0,

lt = new Date();  // 上一次时间

const maxFrame = 90, // 最大帧数90帧

fps = 20; // 每秒20帧

function loop() {

    const now = new Date(),  // 当前时间

    secs = (now - lt) / 1000, // 时间差

    per = frame / maxFrame;  // 进度

    if (secs > 1 / fps) {   // 时间差大于1/20

        const colorI = [];

        let i = 6 * 6;

        while (i--) {

            colorI.push(Math.floor(4 * Math.random()))

        }

        drawMethod.grid(ctx, canvas, {

            w: 6,

            h: 6,

            colorI: colorI

        });

        texture.needsUpdate = true;  // 更新纹理

        mesh.rotation.y = Math.PI * 2 * per;

        renderer.render(scene, camera);

        frame += fps * secs;  // 帧数累加

        frame %= maxFrame;   // 帧数取模，防止帧数溢出



        lt = now;

    }

    // 渲染场景和相机

    requestAnimationFrame( loop );

}

你可以看到这里每个面上被绘制了36个小矩形，并通过一下代码，随机填充颜色

while (i--) {

    colorI.push(Math.floor(4 * Math.random()))

}

以上就是本章的所有内容，这里并未展示完整案例代码，是希望大家能动手练一练，很多的概念，看似晦涩难懂，实则动手尝试下的话秒懂。

Spring 状态机与事件机制插件开发示例

我将为您演示一个完整的 Spring 状态机实现，包含状态机配置、事件机制和可扩展的插件体系。以下是一个订单处理系统的示例：

1. 添加依赖（pom.xml）

<dependencies>

    <!-- Spring State Machine -->

    <dependency>

        <groupId>org.springframework.statemachine</groupId>

        <artifactId>spring-statemachine-starter</artifactId>

        <version>4.2.0</version>

    </dependency>

    

    <!-- Spring Event 相关 -->

    <dependency>

        <groupId>org.springframework</groupId>

        <artifactId>spring-context-support</artifactId>

        <version>6.0.9</version>

    </dependency>

</dependencies>

2. 定义核心接口和类

2.1 状态和事件枚举

// 状态枚举

public enum OrderState {

    NEW, 

    PAYMENT_PENDING, 

    PAID, 

    SHIPPED, 

    DELIVERED, 

    CANCELLED

}



// 事件枚举

public enum OrderEvent {

    CREATE_ORDER, 

    INITIATE_PAYMENT, 

    PAYMENT_COMPLETED, 

    SHIP_ORDER, 

    DELIVERY_CONFIRMED, 

    CANCEL_ORDER

}

2.2 插件接口定义

// 状态变更监听器接口

public interface StateChangeListener {

    void onStateChange(OrderState from, OrderState to, String orderId);

}



// 订单操作插件接口

public interface OrderOperationPlugin {

    void execute(String orderId, OrderState currentState);

}



// 插件管理器接口

public interface PluginManager {

    void registerStateChangeListener(StateChangeListener listener);

    void notifyStateChange(OrderState from, OrderState to, String orderId);

    void executePlugins(String orderId, OrderState currentState);

}

3. 实现状态机配置

@Configuration

@EnableStateMachine

public class OrderStateMachineConfig extends EnumStateMachineConfigurerAdapter<OrderState, OrderEvent> {



    @Autowired

    private List<OrderOperationPlugin> plugins;



    @Override

    public void configure(StateMachineStateConfigurer<OrderState, OrderEvent> states) throws Exception {

        states

            .withStates()

            .initial(OrderState.NEW)

            .state(OrderState.PAYMENT_PENDING)

            .junction(OrderState.PAID)

            .end(OrderState.DELIVERED)

            .end(OrderState.CANCELLED)

            .fork(OrderState.SHIPPED);

    }



    @Override

    public void configure(StateMachineTransitionConfigurer<OrderState, OrderEvent> transitions) throws Exception {

        transitions

            .withExternal()

                .source(OrderState.NEW).target(OrderState.PAYMENT_PENDING)

                .event(OrderEvent.CREATE_ORDER)

                

            .and().withExternal()

                .source(OrderState.PAYMENT_PENDING).target(OrderState.PAID)

                .event(OrderEvent.INITIATE_PAYMENT)

                

            .and().withExternal()

                .source(OrderState.PAID).target(OrderState.SHIPPED)

                .event(OrderEvent.SHIP_ORDER)

                

            .and().withExternal()

                .source(OrderState.SHIPPED).target(OrderState.DELIVERED)

                .event(OrderEvent.DELIVERY_CONFIRMED)

                

            .and().withExternal()

                .source(OrderState.NEW).target(OrderState.CANCELLED)

                .event(OrderEvent.CANCEL_ORDER)

                

            .and().withExternal()

                .source(OrderState.PAYMENT_PENDING).target(OrderState.CANCELLED)

                .event(OrderEvent.CANCEL_ORDER);

    }

    

    @Bean

    public PluginManager pluginManager() {

        return new DefaultPluginManager(plugins);

    }

}

4. 插件实现

4.1 默认插件管理器

@Component

public class DefaultPluginManager implements PluginManager {

    private final List<StateChangeListener> stateChangeListeners = new ArrayList<>();

    private final List<OrderOperationPlugin> operationPlugins;



    public DefaultPluginManager(List<OrderOperationPlugin> plugins) {

        this.operationPlugins = plugins;

    }



    @Override

    public void registerStateChangeListener(StateChangeListener listener) {

        stateChangeListeners.add(listener);

    }



    @Override

    public void notifyStateChange(OrderState from, OrderState to, String orderId) {

        stateChangeListeners.forEach(listener -> listener.onStateChange(from, to, orderId));

    }



    @Override

    public void executePlugins(String orderId, OrderState currentState) {

        operationPlugins.forEach(plugin -> plugin.execute(orderId, currentState));

    }

}

4.2 示例插件实现

// 日志记录插件

@Component

public class LoggingPlugin implements OrderOperationPlugin {

    @Override

    public void execute(String orderId, OrderState currentState) {

        System.out.println("订单 " + orderId + " 当前状态: " + currentState + " - 正在记录日志");

    }

}



// 邮件通知插件

@Component

public class EmailNotificationPlugin implements OrderOperationPlugin {

    @Override

    public void execute(String orderId, OrderState currentState) {

        System.out.println("订单 " + orderId + " 当前状态: " + currentState + " - 发送邮件通知");

    }

}



// 库存管理插件

@Component

public class InventoryUpdatePlugin implements OrderOperationPlugin {

    @Override

    public void execute(String orderId, OrderState currentState) {

        if (currentState == OrderState.PAID) {

            System.out.println("订单 " + orderId + " 已支付，正在更新库存");

        }

    }

}

5. 状态监听器实现

@Component

public class AuditStateChangeListener implements StateChangeListener {

    @Override

    public void onStateChange(OrderState from, OrderState to, String orderId) {

        System.out.println("订单状态变更: " + orderId + " 从 " + from + " 到 " + to + " - 审计记录已创建");

    }

}

6. 服务层实现

@Service

public class OrderService {



    @Autowired

    private StateMachine<OrderState, OrderEvent> stateMachine;



    @Autowired

    private PluginManager pluginManager;



    public OrderService() {

        // 注册监听器

        pluginManager.registerStateChangeListener(new AuditStateChangeListener());

    }



    public void handleOrderEvent(String orderId, OrderEvent event) {

        try {

            stateMachine.start();

            OrderState currentState = stateMachine.getState().getId();

            

            // 发送事件

            stateMachine.sendEvent(event);

            

            OrderState newState = stateMachine.getState().getId();

            

            // 触发状态变更监听器

            if (currentState != newState) {

                pluginManager.notifyStateChange(currentState, newState, orderId);

            }

            

            // 执行操作插件

            pluginManager.executePlugins(orderId, newState);

            

        } catch (Exception e) {

            System.err.println("处理订单事件失败: " + e.getMessage());

        } finally {

            stateMachine.stop();

        }

    }

}

7. 控制器示例

@RestController

@RequestMapping("/orders")

public class OrderController {



    @Autowired

    private OrderService orderService;



    @PostMapping("/{orderId}/events")

    public ResponseEntity<String> sendEvent(@PathVariable String orderId, @RequestParam String event) {

        try {

            OrderEvent orderEvent = OrderEvent.valueOf(event.toUpperCase());

            orderService.handleOrderEvent(orderId, orderEvent);

            return ResponseEntity.ok("事件已处理: " + event);

        } catch (IllegalArgumentException e) {

            return ResponseEntity.badRequest().body("无效的事件类型: " + event);

        }

    }

    

    @GetMapping("/{orderId}/status")

    public ResponseEntity<String> checkStatus(@PathVariable String orderId) {

        // 这里应该从存储中获取当前状态，为简化示例返回固定值

        return ResponseEntity.ok("订单 " + orderId + " 当前状态: 示例状态");

    }

}

8. 可扩展性说明

如何添加新插件：

@Component

public class NewFeaturePlugin implements OrderOperationPlugin {

    @Override

    public void execute(String orderId, OrderState currentState) {

        // 新功能逻辑

    }

}

如何添加新状态监听器：

@Component

public class NewStateChangeListener implements StateChangeListener {

    @Override

    public void onStateChange(OrderState from, OrderState to, String orderId) {

        // 新监听器逻辑

    }

}

使用示例：

# 创建订单

POST /orders/123/events?event=CREATE_ORDER



# 发起支付

POST /orders/123/events?event=INITIATE_PAYMENT



# 发货

POST /orders/123/events?event=SHIP_ORDER



# 确认送达

POST /orders/123/events?event=DELIVERY_CONFIRMED



# 取消订单

POST /orders/123/events?event=CANCEL_ORDER

这个实现具有以下特点：

您可以根据具体业务需求扩展更多状态、事件和插件功能。

使用 LangChain 等 Python 工具，可以更轻松地实现多智能体系统，从而创建超越简单自动化的智能系统。

译自Collaborative Intelligence in Multiagent Systems With Python，作者 Oladimeji Sowole。

近年来，大型语言模型 (LLM)通过生成类似人类的文本、解决复杂问题和自主执行任务，重新定义了人工智能的能力。

然而，随着任务变得更加复杂和跨学科，单个 AI 模型可能并不总是足够。这就是多智能体系统(MAS) 在 LLM 中的概念发挥作用的地方。MAS 允许多个 AI 智能体协作，每个智能体专门负责问题的不同方面，共同努力实现共同目标。

本教程将使用Python探索 LLM 中多智能体系统的最新趋势。我们将介绍什么是多智能体系统、它们为什么重要以及如何使用 LangChain 等工具使用 Python 分步实现它们。

什么是多智能体系统？

多智能体系统 (MAS) 是一个环境，其中多个自主智能体相互交互、合作甚至竞争以解决问题。每个智能体都有自己的能力、优势和关注领域，使系统能够更有效地处理复杂的任务。这些系统在需要协作、并行任务执行甚至协商的场景中表现出色。

在 LLM 中，多智能体系统可以：

• 协作完成需要多个专业领域的任务（例如，一个智能体专注于数学，而另一个智能体处理自然语言理解）。


• 互相协商以解决目标冲突。


• 并行解决复杂的、多步骤的问题，提高速度和准确性。

多智能体系统的用例

• 财务规划: 一个智能体可以专注于分析股票趋势，而另一个智能体可以预测市场的未来行为。


• 医疗保健: 一个智能体专注于诊断分析，而另一个智能体协助患者病史回顾，共同为全面的医疗保健建议提供帮助。


• 供应链优化: 智能体可以专门从事物流、采购或需求预测，从而改善整个供应链的决策。

为什么要使用多智能体系统？

• 专业化: 不同的智能体专门负责不同的任务，使解决问题更加高效。


• 并行性: 智能体可以同时工作，显着减少完成多步骤操作所需的时间。


• 协作: 多个智能体共同努力，利用其独特的优势来实现最佳结果。


• 适应性: 智能体可以实时协商或调整策略，以适应不断变化的任务。

使用 Python 设置多智能体系统

让我们从理论转向实践。在本节中，我们将演示如何使用 Python 和 LangChain 库构建多智能体系统，该库允许不同 LLM 支持的智能体之间无缝交互。

安装依赖项

首先，我们需要安装 LangChain 并设置一个 LLM 服务，例如 OpenAI。

pip install langchain openai

您还需要一个 OpenAI API 密钥，您可以通过注册 OpenAI 的 API 服务来获取。

初始化智能体和工具

首先，我们将定义我们的 LLM（GPT 模型）以及我们的智能体将使用的一组工具。这些工具可以是任何东西，从计算器到网络搜索功能。让我们初始化协作解决涉及信息检索和数学计算的任务的智能体。

from langchain.agents import initialize_agent, load_tools

from langchain.llms import OpenAI



# Initialize OpenAI model

llm = OpenAI(api_key="your_openai_api_key", model="gpt-4")



# Load tools (agents) such as search and calculator

tools = load_tools(["serpapi", "calculator"], llm)



# Initialize a multi-agent system

multi_agent = initialize_agent(

    tools, 

    llm, 

    agent_type="multi-agent", 

    verbose=True

)



# Example task: Find the exchange rate of USD to EUR and calculate for 1500 units

task = "What is the current exchange rate of USD to EUR? Multiply it by 1500."



# Run the multi-agent system to complete the task

result = multi_agent.run(task)

print(result)

工作原理

• 智能体协作: 在此示例中，一个智能体使用搜索工具（例如 SERP API）获取实时汇率，而另一个智能体使用计算器工具将汇率乘以 1,500。


• 任务分解: LLM 将任务分解为子任务（获取汇率和执行计算），并将这些子任务分配给相应的智能体。

构建复杂的智能体系统

现在我们已经看到了一个基本示例，让我们构建一个更复杂的系统，该系统涉及多个智能体来解决问题的不同部分。考虑一个场景，我们正在构建一个旅行助手，它可以处理与预订航班、查看天气和执行预算计算相关的多个查询。

分步代码：旅行助手多智能体系统

# Define task-specific tools

from langchain.tools import Tool



# Weather checking tool

def get_weather(city):

    return f"The weather in {city} is sunny with a temperature of 25°C."



# Flight booking tool

def book_flight(destination, date):

    return f"Flight to {destination} on {date} has been booked."



# Budget calculation tool

def calculate_budget(amount, expenses):

    remaining = amount - sum(expenses)

    return f"Your remaining budget is {remaining}."



# Define our agents

weather_tool = Tool("get_weather", get_weather)

flight_tool = Tool("book_flight", book_flight)

budget_tool = Tool("calculate_budget", calculate_budget)



# Combine agents int0 a multi-agent system

tools = [weather_tool, flight_tool, budget_tool]

multi_agent = initialize_agent(tools, llm, agent_type="multi-agent", verbose=True)



# Example task

task = """

I want to book a flight to Paris for December 20th, check the weather in Paris, 

and calculate my remaining budget if I have $2000 and my expenses are $500 and $300.

"""



# Execute the multi-agent system

result = multi_agent.run(task)

print(result)

发生了什么？

• 航班智能体:book_flight智能体处理任务的航班预订部分。


• 天气智能体:get_weather智能体检索巴黎的天气数据。


• 预算智能体:calculate_budget智能体根据用户的输入计算用户的剩余预算。

在这种情况下，每个代理都负责解决更大问题中的特定部分，并协同工作以提供全面的结果。整个过程由 LLM 驱动，LLM 协调代理的工作。

多代理系统的先进用例

医疗保健协作

在医疗保健领域，不同的代理可以专注于患者治疗过程的不同部分。例如：

• 一个代理可以分析医学影像。


• 另一个代理审查患者的病史。


• 第三个代理提供诊断建议。

通过协同工作，这些代理可以生成一份综合报告，帮助做出更准确、更快速的医疗决策。

供应链优化

多代理系统可用于管理供应链的不同方面：

• 物流代理跟踪运输时间。


• 采购代理监控库存水平。


• 预测代理预测未来需求。

它们共同可以优化供应链，减少延误，降低成本，提高整体效率。

结论

多代理系统 (MAS) 代表了人工智能驱动解决方案发展中的一个突破性趋势。通过允许多个代理协同工作，每个代理都有自己的专业领域，MAS 极大地提高了大规模问题解决任务的效率和有效性。借助 LangChain 等 Python 工具，实现多代理系统变得越来越容易，使开发人员能够创建超越简单自动化的智能系统。

您是否想探索与 AI 代理和 Python 合作的可能性？阅读 Andela 的博客，了解如何在 Python 中使用 LangGraph 开发主 AI 代理！

本文在云云众生（yylives.cc/）首发，欢迎大家访问。