2024年9月

Java SE 23 新增特性

作者:
Grey

原文地址:

博客园:Java SE 23 新增特性

CSDN:Java SE 23 新增特性

源码

源仓库:
Github:java_new_features

Primitive Types in Patterns, instanceof, and switch (预览功能)

通过 instanceof 和 switch,我们可以检查对象是否属于特定类型,如果是,则将该对象绑定到该类型的变量,执行特定的程序路径,并在该程序路径中使用新变量。

public class PrimitiveTypesTest {
    void main() {
        test1("hello world");
        test2("hello world");
        test1(56);
        test2(56);
        test1(java.time.LocalDate.now());
        test2(java.time.LocalDate.now());
    }

    private static void test1(Object obj) {
        if (obj instanceof String s && s.length() >= 5) {
            System.out.println(s.toUpperCase());
        } else if (obj instanceof Integer i) {
            System.out.println(i * i);
        } else {
            System.out.println(obj);
        }
    }

    private static void test2(Object obj) {
        switch (obj) {
            case String s when s.length() >= 5 -> System.out.println(s.toUpperCase());
            case Integer i -> System.out.println(i * i);
            case null, default -> System.out.println(obj);
        }
    }
}

JEP 455
在 Java 23 中引入了两项变更:

  • 可以在 switch 表达式和语句中使用所有基元类型,包括 long、float、double 和 boolean。

  • 其次,我们还可以在模式匹配中使用所有基元类型,包括 instanceof 和 switch。

在这两种情况下,即通过 long、float、double 和布尔类型进行 switch 以及使用基元变量进行模式匹配时,与所有新的 switch 功能一样,switch 必须要涵盖所有可能的情况。

private static void test3(int x) {
    switch (x) {
        case 1, 2, 3 -> System.out.println("Low");
        case 4, 5, 6 -> System.out.println("Medium");
        case 7, 8, 9 -> System.out.println("High");
    }
}

Module Import Declarations (模块导入声明,预览功能)

通过简洁地导入模块导出的所有包的功能来增强 Java 编程语言。这简化了模块库的重复使用,但不要求导入代码本身必须在模块中。这是一项预览语言功能。

自 Java 1.0 起,
java.lang
包中的所有类都会自动导入到每个 .java 文件中。这就是为什么我们无需导入语句就能使用
Object

String

Integer

Exception

Thread
等类的原因。

我们还可以导入完整的包。例如,导入
java.util.*
意味着我们不必单独导入
List

Set

Map

ArrayList

HashSet

HashMap
等类。

JEP 467
现在允许我们导入完整的模块,更准确地说,是导入模块导出的包中的所有类。

例如,我们可以按如下方式导入完整的
java.base
模块,然后使用该模块中的类(例如
List

Map

Collectors

Stream
),而无需进一步导入:

package git.snippets.jdk23;

import module java.base;

public class ModuleImportDeclarationsTest {
    void main() {
        System.out.println(groupByFirstLetter("a", "abc", "bcd", "ddd", "dddc", "dfc", "bc"));
    }

    public static Map<Character, List<String>> groupByFirstLetter(String... values) {
        return Stream.of(values).collect(Collectors.groupingBy(s -> Character.toUpperCase(s.charAt(0))));
    }
}

如果有两个同名的导入类,例如下面示例中的 Date,编译器就会出错:

import module java.base;
import module java.sql;

如果一个导入模块临时导入了另一个模块,那么我们也可以使用临时导入模块导出包中的所有类,而无需显式导入。

例如,java.sql 模块转义导入了 java.xml 模块:

module java.sql {
  . . .
  requires transitive java.xml;
  . . .
}

因此,在下面的示例中,我们不需要显式导入 SAXParserFactory 和 SAXParser,也不需要显式导入 java.xml 模块:

SAXParserFactory factory = SAXParserFactory.newInstance();
SAXParser saxParser = factory.newSAXParser();

Flexible Constructor Bodies (二次预览)

在 JDK 23 之前,下述代码中,Child1的构造函数,只能先通过super构造父类,然后才能初始化子类的 b 这个变量。

public class FlexibleConstructorBodies {
    void main() {
        new Child1(1, 2);
    }
}


class Parent {
    private final int a;

    public Parent(int a) {
        this.a = a;
        printMe();
    }

    void printMe() {
        System.out.println("a = " + a);
    }
}

// JDK 23 之前
class Child1 extends Parent {
    private final int b;

    public Child1(int a, int b) {
        super(verifyParamsAndReturnA(a, b));
        this.b = b;
    }

    @Override
    void printMe() {
        super.printMe();
        System.out.println("b = " + b);
    }

    private static int verifyParamsAndReturnA(int a, int b) {
        if (a < 0 || b < 0) throw new IllegalArgumentException();
        return a;
    }
}

当我们执行

new Child1(1,2);

这段代码的时候,本来我们期待返回的是

a = 1
b = 2

但是由于父类在构造时候调用了
printMe()
,且这个调用是在 b 变量初始化之前调用的,所以导致程序执行的结果是

a = 1
b = 0

今后,在使用 super(...) 调用超级构造函数之前,以及在使用 this(...) 调用替代构造函数之前,我们可以执行任何不访问当前构造实例(即不访问其字段)的代码

此外,我们还可以初始化正在构造的实例的字段。详见
JEP 482

在 JDK 23 上,上述代码可以调整为:

class Child2 extends Parent {
    private final int b;

    public Child2(int a, int b) {
        if (a < 0 || b < 0) throw new IllegalArgumentException();  // ⟵ Now allowed!
        this.b = b;                                                // ⟵ Now allowed!
        super(a);
    }

    @Override
    void printMe() {
        super.printMe();
        System.out.println("b = " + b);
    }
}

其中构造函数中,a和b的初始化和判断,都可以在super(...)函数调用之前,
执行

new Child2(1,2);

打印结果为预期结果

a = 1
b = 2

Implicitly Declared Classes and Instance Main Methods (第三次预览)

最早出现在 JDK 21 中,见
Java SE 21 新增特性

原来我们写一个main方法,需要

public class UnnamedClassesAndInstanceMainMethodsTest {

    public static void main(String[] args) {
        System.out.println("Hello World!");
    }

}

而且Java文件的名称需要和UnnamedClassesAndInstanceMainMethodsTest保持一致,到了JDK 23,上述代码可以简化成

void main() {
    System.out.println("hello world");
}

甚至连 public class ... 这段也不需要写。

更多

Java SE 7及以后各版本新增特性,持续更新中...

参考资料

Java Language Changes for Java SE 23

JDK 23 Release Notes

JAVA 23 FEATURES(WITH EXAMPLES

不知道你在开发过程中有没有遇到过这样的困惑:这个变量怎么值被改?这个值怎么没变?

今天就来和大家分享可能导致这个问题的根本原因值传递 vs 引用传递。

在此之前我们先回顾两组基本概念:

值类型 vs 引用类型

值类型:
直接存储数据,数据存储在栈上;

引用类型:
存储数据对象的引用,数据实际存储在堆上。

形参 vs 实参

形参:
即形式参数,表示调用方法时,方法需要你传递的值。方法声明定义了其形参。也就是说在定义方法时,紧跟在方法名后面括号中的参数列表就是形参。

实参:
即实际参数,表示调用方法时,你传递给方法形参的值。调用代码在调用过程时提供实参。也就是说在调用方法时,紧跟在方法名后面括号中的参数列表就是实参。

再来回顾一下值类型和引用类型在内存中是怎么存储的呢?

对于值类型变量的值直接存储在栈中,如下图的int a=10,10就直接存在栈空间中,而其栈空间对应的内存地址为0x66666668;对于引用类型变量本身存储的是实例对象的引用,即实例对象在堆中的实际内存地址,因此引用类型变量是存储其实例对象的引用于栈上,如下图中变量Test a在栈中实际存储的是实例对象Test a在堆中的内存地址0x88888880,而栈空间对应的内存地址为0x66666668。

栈也是有内存地址的,这一点很重要,无论栈空间上存储的是值还是引用地址,这个栈空间本身也有自己对应的内存地址。

什么是值传递?什么是引用传递?

值传递
:如果变量按值传递给方法,则会把变量的副本传递给方法。对于值类型则把
变量的副本
传递给方法,对于引用类型则把
变量的引用的副本
传递给方法。因此被调用方法参数会创建一个新的内存地址用于接收存储变量,因此在方法内部对变量修改并不会影响原来的值。

引用传递
:如果变量按引用传递给方法,则会把变量的引用传递给方法,对于值类型则把
变量的栈空间地址
传递给方法,对于引用类型则把
变量的引用的栈空间地址
传递给方法。因此被调用方法参数不会创建一个新的内存地址用于接收存储变量,意味着形参与实参共同指向相同的内存地址,因此在方法内部修对变量修改会影响原来的值。

上面的描述可能有点拗口,下面我们在基于值类型、引用类型、值传递、引用传递各种组合进行一个详细说明。

01
、值类型按值传递

当值类型按值传递时,调用者会把值类型变量的副本传递给方法,因此被调用方法参数会创建一个新的内存地址用于接收存储变量,因此当在方法内部对参数进行修改时并不会影响调用者调用处的值类型变量。

传递值类型变量的副本就是相当于在栈上,又复制了一个同样的值,而且内存地址还不一样,所以互不影响。如下图把a赋值给b,则b直接新开辟了一个栈空间,虽然a和b都是10,但是它们在不同的地址空间中,因此如果他们各自被修改了,也互不影响。

下面我们写个例子演示一下,这个例子就是定义个变量a并赋值,然后调用一个方法此方法内对传进来的参数a进行加1,具体代码如下:

public static void ValueByValueRun()
{
    var a = 10;
    Console.WriteLine($"调用者-调用方法前 a 值:{a}");
    ChangeValueByValue(a);
    Console.WriteLine($"调用者-调用方法后 a 值:{a}");
}
public static void ChangeValueByValue(int a)
{
    Console.WriteLine($"    被调用方法-接收到 a 值:{a}");
    a = a + 1;
    Console.WriteLine($"    被调用方法-修改后 a 值:{a}");
}

运行结果如下:

通过代码执行结果可以发现,方法内对变量的修改已经生效,但是不没有影响到调用者调用处的变量值。

02
、引用类型按值传递

当引用类型按值传递时,调用者会把引用类型变量的引用副本传递给方法,因此被调用方法参数会创建一个新的内存地址用于接收存储变量,而对于一个引用类型变量来说其本身存储的就是引用类型实例对象的引用副本,而方法接收到的也是此变量引用的副本,所以调用者参数和被调用方法参数是引用了同一个实例对象的两个引用副本。如下图Test a可以理解为调用者传的实参,Test b可以理解为被调用方法定义的形参,这两个参数都只是指向堆中Test a的引用副本。

因此可以得出两个结论:

1、变量a和b都是指向实例对象Test a的引用,所以无论变量a或b,只要有一个更新了实例成员则另一个变量也会同步发生变化。

2、虽然变量a和b都是指向实例对象Test a的引用,但是他们存储在栈上的内存地址却不同,因此如果他们各种重新分配实例也就是new一个新对象,则另一个变量无法感知到还是保持原因状态不变。

我们先用代码说明第一个结论:

public static void ChangeReferenceByValueRun()
{
    var a = new Test
    {
        Age = 10
    };
    Console.WriteLine($"调用者-调用方法前 a.Age 值:{a.Age}");
    ChangeReferenceByValue(a);
    Console.WriteLine($"调用者-调用方法后 a.Age 值:{a.Age}");
}
public static void ChangeReferenceByValue(Test a)
{
    Console.WriteLine($"    被调用方法-接收到 a.Age 值:{a.Age}");
    a.Age = a.Age + 1;
    Console.WriteLine($"    被调用方法-修改后 a.Age 值:{a.Age}");
}

运行结果如下:

可以看到被调用方法中a实例对象的Age属性发生变化后,调用者中变量也同步发生了变化。

对于第二个结论我们这样论证,在方法中直接对参数new一个新对象,看看原变量是否发生变化,代码如下:

public static void NewReferenceByValueRun()
{
    var a = new Test
    {
        Age = 10
    };
    Console.WriteLine($"调用者-调用方法前 a.Age 值:{a.Age}");
    NewReferenceByValue(a);
    Console.WriteLine($"调用者-调用方法后 a.Age 值:{a.Age}");
}
public static void NewReferenceByValue(Test a)
{
    Console.WriteLine($"    被调用方法-接收到 a.Age 值:{a.Age}");
    a = new Test
    {
        Age = 100
    };
    Console.WriteLine($"    被调用方法-new后 a.Age 值:{a.Age}");
}

执行结果如下:

可以发现当在方法中对变量执行new操作后,调用者处的变量并没有发生变化。

为什么会这样呢?因为对于引用类型来说,形参和实参是对引用类型的实例对象引用的两个副本,而这两个副本存储在栈上又分别在不同的内存地址空间上,而new主要就是重新分配内存,这就导致形参变量a=new后,栈上形参变量a指向了Test新的实例对象的引用,而实参变量a还是保持原有实例对象引用不变。

如下图所示。

03
、值类型按引用传递

当值类型按引用传递时,调用者会把值类型变量对应的栈空间地址传递给方法,因此被调用方法参数不会创建一个新的内存地址用于接收存储变量,因此当在方法内部对参数进行修改时并同样会影响调用者调用处的值类型变量。

传递值类型变量对应的栈空间地址就意味着形参与实参共同指向相同的内存地址,所以才导致对形参修改时,实参也会同步发生变化。

我们用一个小例子演示一下:

public static void ValueByReferenceRun()
{
    Console.WriteLine($"值类型按引用传递");
    var a = 10;
    Console.WriteLine($"调用者-调用方法前 a 值:{a}");
    ChangeValueByReference(ref a);
    Console.WriteLine($"调用者-调用方法后 a 值:{a}");
}
public static void ChangeValueByReference(ref int a)
{
    Console.WriteLine($"    被调用方法-接收到 a 值:{a}");
    a = a + 1;
    Console.WriteLine($"    被调用方法-修改后 a 值:{a}");
}

执行结果如下:

可以发现调用者处的值类型变量已经发生改变。

04
、引用类型按引用传递

当引用类型按引用传递时,调用者会把引用类型变量对应的栈空间地址传递给方法,因此被调用方法参数不会创建一个新的内存地址用于接收存储变量,因此当在方法内部对参数进行修改时并同样会影响调用者调用处的引用类型变量。

传递引用类型变量对应的栈空间地址就意味着形参与实参共同指向相同的内存地址,因此对形参修改时,实参也会同步发生变化,而且这个里的修改不单单指修改实例成员,还包括new一个新实例对象。

下面我们看一个修改实例成员的例子:

public static void ChangeReferenceByReferenceRun()
{
    Console.WriteLine($"引用类型按引用传递 - 修改实例成员");
    var a = new Test
    {
        Age = 10
    };
    Console.WriteLine($"调用者-调用方法前 a.Age 值:{a.Age}");
    ChangeReferenceByReference(ref a);
    Console.WriteLine($"调用者-调用方法后 a.Age 值:{a.Age}");
}
public static void ChangeReferenceByReference(ref Test a)
{
    Console.WriteLine($"    被调用方法-接收到 a.Age 值:{a.Age}");
    a.Age = a.Age + 1;
    Console.WriteLine($"    被调用方法-修改后 a.Age 值:{a.Age}");
}

执行结果如下:

再看看new一个新对象的例子:

public static void NewReferenceByReferenceRun()
{
    Console.WriteLine($"引用类型按引用传递 - new 新实例");
    var a = new Test
    {
        Age = 10
    };
    Console.WriteLine($"调用者-调用方法前 a.Age 值:{a.Age}");
    NewReferenceByReference(ref a);
    Console.WriteLine($"调用者-调用方法后 a.Age 值:{a.Age}");
}
public static void NewReferenceByReference(ref Test a)
{
    Console.WriteLine($"    被调用方法-接收到 a.Age 值:{a.Age}");
    a = new Test
    {
        Age = 100
    };
    Console.WriteLine($"    被调用方法-new后 a.Age 值:{a.Age}");
}

执行结果如下:

另外string是一个特殊的引用类型,string类型变量的按值传递和按引用传递和值类型是一致的,也就是要把string类型当值类型一样看待就行。string类型的特殊性我们后面会单独具体介绍。

在C#中以下修饰符可应用与参数声明,并且会使得参数按引用传递:ref、out、readonly ref、in。对于每个修饰符具体怎么使用就不再这里细说了。

相信到这里你应该就可以回答我之前在《LeetCode题集-2 - 两数相加》最后提的问题了。


:测试方法代码以及示例源码都已经上传至代码库,有兴趣的可以看看。
https://gitee.com/hugogoos/Planner

代码整洁之道

image-20240904225436374

简介:

本书是编程大师“Bob 大叔”40余年编程生涯的心得体会的总结,讲解要成为真正专业的程序员需要具备什么样的态度,需要遵循什么样的原则,需要采取什么样的行动。作者以自己以及身边的同事走过的弯路、犯过的错误为例,意在为后来者引路,助其职业生涯迈上更高台阶。

本书适合所有程序员阅读,也可供所有想成为具备职业素养的职场人士参考。

第十三章 团队与项目

image-20240919070111183

小项目该如何实施?如何给程序员分派?大项目又该如何实施?

13.1 团队开发仅仅是简单的混合吗?

这几年来,我为许多银行和保险公司做过咨询。这些公司看起来有一个共同点,那就是它们都是以一种古怪的方式来分派项目的。

银行的项目通常相对比较小,
只需一到两名程序员工作几周即可

这样的项目通常会配备一名项目经理,但他同时还会管理其他若干项目;会配备一名业务分析师,但他同时也为其他项目服务;也会配备几名程序员,他们同样同时参与其他项目的工作;还会配备一到两名测试人员,他们也同时测试其他项目。看到其中的模式了吧?这些项目太小,无法把一个人的全部时间完全分配其中。每个人在项目上的投入都是以50%甚至25%的比例来计算的。

但是,不要忘了:事实上并没有半个人的这种说法。

让一个程序员把一半的时间投入在项目A中,把其余时间投入在项目B中,这并不可行,尤其是当这两个项目的项目经理不同、业务分析师不同、程序员不同、测试人员不同时,更不可行。这种丑陋的组合方式能称为团队吗?这不是团队,只是从榨汁机中榨出的混合物而已。

有凝聚力的团队:

形成团队是需要时间的。
团队成员需要首先建立关系。他们需要学习如何互相协作,需要了解彼此的癖好、强项、弱项,最终,才能凝聚成团队。

有凝聚力的团队确实有些神奇之处。
他们能够一起创造奇迹。他们互为知己,能够替对方着想,互相支持,激励对方拿出自己最好的表现。他们攻无不克。

团队的人员组成及其比例:

  • 有凝聚力的团队通常有大约12名成员。最多的可以有20人,最少可以只有3个人,但是12个人是最好的。这个团队应该配有
    程序员、测试人员和分析师
    ,同时还要有一名
    项目经理
  • 程序员算一组,测试人员和分析师算一组,两组人数比例没有固定限制,但2∶1是比较好的组合。
  • 由12个人组成的理想团队,人员配备情况是这样的:7名程序员、2名测试人员、2名分析师和1名项目经理。

团队组成人员的分工与职责:

分析师与测试人员:

  • 分析师开发需求,为需求编写自动化验收测试。测试人员也会编写自动化验收测试,但是他们两者的视角是不同的。两者虽然都写需求,但是分析师关注业务价值,而测试人员关注正确性。
  • 分析师编写成功路径场景;测试人员要关心的是那些可能出错的地方,他们编写的是失败场景和边界场景。

项目经理:
项目经理跟踪项目团队的进度,确保团队成员理解项目时间表和优先级。

监督人员
:其中有一名团队成员可能会拿出部分时间充任团队教练或Master[2]的角色,
负责确保项目进展,监督成员遵守纪律。
他们担负的职责是,如果团队因为项目压力太大选择半途而废,他们应当充当中流砥柱。

团队的发酵期:

  • 成员克服个体差异性,默契配合,彼此信任,形成真正有凝聚力的团队,是需要一些时间的,可能需要6个月,甚至1年。
  • 凝聚力一旦真正形成,就会产生一种神奇的魔力。团队的成员会一起做计划,一起解决问题,一起面对问题,一起搞定一切。
  • 团队已经有了凝聚力,但却因为项目结束了就解散这样的团队,则是极为荒谬的。最好的做法是不拆散团队,让他们继续合作,只要不断地把新项目分派给他们就行。

团队和项目,何者为先?

专业的开发组织会把项目分配给已形成凝聚力的团队,而不会围绕着项目来组建团队。一个有凝聚力的团队能够同时承接多个项目,根据成员各自的意愿、技能和能力来分配工作,会顺利完成项目。

如何管理有凝聚力的团队?

管理团队的项目速度:

每个团队都有自己的速度。团队的速度,即是指在一定时间段内团队能够完成的工作量。有些团队使用每周点数来衡量自己的速度,其中“点数”是一种关于复杂度的单位。他们对每个工作项目的特性进行分解,使用点数来估算。然后以每周能完成的点数来衡量速度。管理人员可以对分配给团队的项目设置一个目标值。

项目承包人的困境:

作为项目承包人,如果有一个专属团队完全投入在其项目上,他能够清楚计算出团队的投入是多少。他们明白,组建和解散团队代价高昂,因此公司也不会因为短期原因就调走团队。

如果项目分配给一个有凝聚力的团队,并且如果那些团队同时在做多个项目,那么在公司心血来潮时便可以改变项目的优先级。这可能会影响项目承包人对未来的安全感。他们所依赖的资源,也可能突然间便被抽走。

组建和解散团队只是人为的困难,公司不应受到它的束缚。
如果公司在业务上认为一个项目比另外一个项目的优先级更高,应该要快速重新分配资源。项目承包人的职责所在,便是清晰地定义和陈述项目的价值与意义,让项目得到公司管理层的认可和支持。

13.2 结论

团队比项目更难构建。
因此,组建稳健的团队,让团队在一个又一个项目中整体移动共同工作是较好的做法。并且,团队也可以同时承接多个项目。

在组建团队时,要给予团队充足的时间,让他们形成凝聚力,一直共同工作,成为不断交付项目的强大引擎。

DependencyInjection.StaticAccessor

前言

如何在静态方法中访问DI容器长期以来一直都是一个令人苦恼的问题,特别是对于热爱编写扩展方法的朋友。之所以会为这个问题苦恼,是因为一个特殊的服务生存期——范围内(Scoped),所谓的Scoped就是范围内单例,最常见的WebAPI/MVC中一个请求对应一个范围,所有注册为Scoped的对象在同一个请求中是单例的。如果仅仅用一个静态字段存储应用启动时创建出的
IServiceProvider
对象,那么在一个请求中通过该字段是无法正确获取当前请求中创建的Scoped对象的。

在早些时候有针对肉夹馍(Rougamo)访问DI容器发布了
一些列NuGet
,由于肉夹馍不仅能应用到实例方法上还能够应用到静态方法上,所以肉夹馍访问DI容器的根本问题就是如何在静态方法中访问DI容器。考虑到静态方法访问DI容器是一个常见的公共问题,所以现在将核心逻辑抽离成一系列单独的NuGet包,方便不使用肉夹馍的朋友使用。

快速开始

启动项目引用
DependencyInjection.StaticAccessor.Hosting

dotnet add package DependencyInjection.StaticAccessor.Hosting

非启动项目引用
DependencyInjection.StaticAccessor

dotnet add package DependencyInjection.StaticAccessor

// 1. 初始化。这里用通用主机进行演示,其他类型项目后面将分别举例
var builder = Host.CreateDefaultBuilder();

builder.UsePinnedScopeServiceProvider(); // 仅此一步完成初始化

var host = builder.Build();

host.Run();

// 2. 在任何地方获取
class Test
{
    public static void M()
    {
        var yourService = PinnedScope.ScopedServices.GetService<IYourService>();
    }
}

如上示例,通过静态属性
PinnedScope.ScopedServices
即可获取当前Scope的
IServiceProvider
对象,如果当前不在任何一个Scope中时,该属性返回根
IServiceProvider

版本说明

由于
DependencyInjection.StaticAccessor
的实现包含了通过反射访问微软官方包非public成员,官方的内部实现随着版本的迭代也在不断地变化,所以针对官方包不同版本发布了对应的版本。
DependencyInjection.StaticAccessor
的所有NuGet包都采用语义版本号格式(SemVer),其中主版本号与
Microsoft.Extensions.*
相同,次版本号为功能发布版本号,修订号为BUG修复及微小改动版本号。请各位在安装NuGet包时选择与自己引用的
Microsoft.Extensions.*
主版本号相同的最新版本。

另外需要说明的是,由于我本地创建blazor项目时只能选择.NET8.0,所以blazor相关包仅提供了8.0版本,如果确实有低版本的需求,可以到github中提交issue。

WebAPI/MVC初始化示例

启动项目引用
DependencyInjection.StaticAccessor.Hosting

dotnet add package DependencyInjection.StaticAccessor.Hosting

非启动项目引用
DependencyInjection.StaticAccessor

dotnet add package DependencyInjection.StaticAccessor

var builder = WebApplication.CreateBuilder();

builder.Host.UsePinnedScopeServiceProvider(); // 唯一初始化步骤

var app = builder.Build();

app.Run();

Blazor使用示例

Blazor的DI Scope是一个特殊的存在,在WebAssembly模式下Scoped等同于单例;而在Server模式下,Scoped对应一个SignalR连接。针对Blazor的这种特殊的Scope场景,除了初始化操作,还需要一些额外操作。

我们知道,Blazor项目在创建时可以选择交互渲染模式,除了Server模式外,其他的模式都会创建两个项目,多出来的这个项目的名称以
.Client
结尾。
这里我称
.Client
项目为Client端项目,另一个项目为Server端项目(Server模式下唯一的那个项目也称为Server端项目)。

Server端项目

  1. 安装NuGet

    启动项目引用
    DependencyInjection.StaticAccessor.Blazor


    dotnet add package DependencyInjection.StaticAccessor.Blazor


    非启动项目引用
    DependencyInjection.StaticAccessor


    dotnet add package DependencyInjection.StaticAccessor

  2. 初始化

    var builder = WebApplication.CreateBuilder();
    
    builder.Host.UsePinnedScopeServiceProvider(); // 唯一初始化步骤
    
    var app = builder.Build();
    
    app.Run();
    
  3. 页面继承
    PinnedScopeComponentBase

    推荐直接在
    _Imports.razor
    中声明。

    // _Imports.razor
    
    @inherits DependencyInjection.StaticAccessor.Blazor.PinnedScopeComponentBase
    

Client端项目

与Server端步骤基本一致,只是引用的NuGet有所区别:

  1. 安装NuGet

    启动项目引用
    DependencyInjection.StaticAccessor.Blazor.WebAssembly


    dotnet add package DependencyInjection.StaticAccessor.Blazor.WebAssembly


    非启动项目引用
    DependencyInjection.StaticAccessor


    dotnet add package DependencyInjection.StaticAccessor

  2. 初始化

    var builder = WebAssemblyHostBuilder.CreateDefault(args);
    
    builder.UsePinnedScopeServiceProvider();
    
    await builder.Build().RunAsync();
    
  3. 页面继承
    PinnedScopeComponentBase

    推荐直接在
    _Imports.razor
    中声明。

    // _Imports.razor
    
    @inherits DependencyInjection.StaticAccessor.Blazor.PinnedScopeComponentBase
    

已有自定义ComponentBase基类的解决方案

你可能会使用其他包定义的
ComponentBase
基类,由于C#不支持多继承,所以这里提供了不继承
PinnedScopeComponentBase
的解决方案。

// 假设你现在使用的ComponentBase基类是ThirdPartyComponentBase

// 定义新的基类继承ThirdPartyComponentBase
public class YourComponentBase : ThirdPartyComponentBase, IHandleEvent, IServiceProviderHolder
{
    private IServiceProvider _serviceProvider;

    [Inject]
    public IServiceProvider ServiceProvider
    {
        get => _serviceProvider;
        set
        {
            PinnedScope.Scope = new FoolScope(value);
            _serviceProvider = value;
        }
    }

    Task IHandleEvent.HandleEventAsync(EventCallbackWorkItem callback, object? arg)
    {
        return this.PinnedScopeHandleEventAsync(callback, arg);
    }
}

// _Imports.razor
@inherits YourComponentBase

其他ComponentBase基类

除了
PinnedScopeComponentBase
,还提供了
PinnedScopeOwningComponentBase

PinnedScopeLayoutComponentBase
,后续会根据需要可能会加入更多类型。如有需求,也欢迎反馈和提交PR.

注意事项

避免通过PinnedScope直接操作IServiceScope

虽然你可以通过
PinnedScope.Scope
获取当前的DI Scope,但最好不要通过该属性直接操作
IServiceScope
对象,比如调用Dispose方法,你应该通过你创建Scope时创建的变量进行操作。

不支持非通常Scope

一般日常开发时不需要关注这个问题的,通常的AspNetCore项目也不会出现这样的场景,而Blazor就是官方项目类型中一个非通常DI Scope的案例。

在解释什么是非通常Scope前,我先聊聊通常的Scope模式。我们知道DI Scope是可以嵌套的,在通常情况下,嵌套的Scope呈现的是一种栈的结构,后创建的scope先释放,井然有序。

using (var scope11 = serviceProvider.CreateScope())                    // push scope11. [scope11]
{
    using (var scope21 = scope11.ServiceProvider.CreateScope())        // push scope21. [scope11, scope21]
    {
        using (var scope31 = scope21.ServiceProvider.CreateScope())    // push scope31. [scope11, scope21, scope31]
        {

        }                                                              // pop scope31.  [scope11, scope21]

        using (var scope32 = scope21.ServiceProvider.CreateScope())    // push scope32. [scope11, scope21, scope32]
        {

        }                                                              // pop scope32.  [scope11, scope21]
    }                                                                  // pop scope21.  [scope11]

    using (var scope22 = scope11.ServiceProvider.CreateScope())        // push scope22. [scope11, scope22]
    {

    }                                                                  // pop scope22.  [scope22]
}                                                                      // pop scope11.  []

了解了通常Scope,那么就很好理解非通常Scope了,只要是不按照这种井然有序的栈结构的,那就是非通常Scope。比较常见的就是Blazor的这种情况:

我们知道,Blazor SSR通过SignalR实现SPA,一个SignalR连接对应一个DI Scope,界面上的各种事件(点击、获取焦点等)通过SignalR通知服务端回调事件函数,而这个回调便是从外部横插一脚与SignalR进行交互的,在不进行特殊处理的情况下,回调事件所属的Scope是当前回调事件新创建的Scope,但我们在回调事件中与之交互的
Component
是SignalR所属Scope创建的,这就出现了Scope交叉交互的情况。
PinnedScopeComponentBase
所做的便是在执行回调函数之前,将
PinnedScope.Scope
重设回SignalR对应Scope。

肉夹馍相关应用

正如前面所说,
DependencyInjection.StaticAccessor
的核心逻辑是从肉夹馍的DI扩展中抽离出来的,抽离后肉夹馍DI扩展将依赖于
DependencyInjection.StaticAccessor
。现在你可以直接引用
DependencyInjection.StaticAccessor
,然后直接通过
PinnedScope.Scope
与DI进行交互,但还是推荐通过肉夹馍DI扩展进行交互,DI扩展提供了一些额外的功能,稍后将一一介绍。

DI扩展包变化

Autofac相关包未发生重大变化,后续介绍的扩展包都是官方DependencyInjection的相关扩展包

本次不仅仅是一个简单的代码抽离,代码的核心实现上也有更新,更新后移出了扩展方法
CreateResolvableScope
,直接支持官方的
CreateScope

CreateAsyncScope
方法。同时扩展包
Rougamo.Extensions.DependencyInjection.AspNetCore

Rougamo.Extensions.DependencyInjection.GenericHost
合并为
Rougamo.Extensions.DependencyInjection.Microsoft

Rougamo.Extensions.DependencyInjection.Microsoft

仅定义切面类型的项目需要引用
Rougamo.Extensions.DependencyInjection.Microsoft
,启动项目根据项目类型引用
DependencyInjection.StaticAccessor
相关包即可,初始化也是仅需要完成
DependencyInjection.StaticAccessor
初始化即可。

更易用的扩展

Rougamo.Extensions.DependencyInjection.Microsoft
针对
MethodContext
提供了丰富的DI扩展方法,简化代码编写。

public class TestAttribute : AsyncMoAttribute
{
    public override ValueTask OnEntryAsync(MethodContext context)
    {
        context.GetService<ITestService>();
        context.GetRequiredService(typeof(ITestService));
        context.GetServices<ITestService>();
    }
}

从当前宿主类型实例中获取IServiceProvider

DependencyInjection.StaticAccessor
提供的是一种常用场景下获取当前Scope的
IServiceProvider
解决方案,但在千奇百怪的开发需求中,总会出现一些不寻常的DI Scope场景,比如前面介绍的
非通常Scope
,再比如Blazor。针对这种场景,肉夹馍DI扩展虽然不能帮你获取到正确的
IServiceProvider
对象,但如果你自己能够提供获取方式,肉夹馍DI扩展可以方便的集成该获取方式。

下面以Blazor为例,虽然已经针对Blazor特殊的DI Scope提供了通用解决方案,但Blazor还存在着自己的特殊场景。我们知道Blazor SSR服务生存期是整个SignalR的生存期,这个生存期可能非常长,一个生存期期间可能会创建多个页面(ComponentBase),这多个页面也将共享注册为Scoped的对象,这在某些场景下可能会存在问题(比如共享EF DBContext),所以微软提供了
OwningComponentBase
,它提供了更短的服务生存期,集成该类可以通过
ScopedServices
属性访问
IServiceProvider
对象。

// 1. 定义前锋类型,针对OwningComponentBase返回ScopedServices属性
public class OwningComponentScopeForward : SpecificPropertyFoolScopeProvider, IMethodBaseScopeForward
{
    public override string PropertyName => "ScopedServices";
}

// 2. 初始化
var builder = WebApplication.CreateBuilder();

// 初始化DependencyInjection.StaticAccessor
builder.Host.UsePinnedScopeServiceProvider();

// 注册前锋类型
builder.Services.AddMethodBaseScopeForward<OwningComponentScopeForward>();

var app = builder.Build();

app.Run();

// 3. 使用
public class TestAttribute : AsyncMoAttribute
{
    public override ValueTask OnEntryAsync(MethodContext context)
    {
        // 当TestAttribute应用到OwningComponentBase子类方法上时,ITestService将从OwningComponentBase.ScopedServices中获取
        context.GetService<ITestService>();
    }
}

除了上面示例中提供的
OwningComponentScopeForward
,还有根据字段名称获取的
SpecificFieldFoolScopeProvider
,根据宿主类型通过lambda表达式获取的
TypedFoolScopeProvider<>
,这里就不一一举例了,如果你的获取逻辑更加复杂,可以直接实现先锋类型接口
IMethodBaseScopeForward

除了前锋类型接口
IMethodBaseScopeForward
,还提供了守门员类型接口
IMethodBaseScopeGoalie
,在调用
GetService
系列扩展方法时,内部实现按 [先锋类型 -> PinnedScope.Scope.ServiceProvider -> 守门员类型 -> PinnedScope.RootServices] 的顺序尝试获取
IServiceProvider
对象。

完整示例

完整示例请访问:
https://github.com/inversionhourglass/Rougamo.DI/tree/master/samples

云上分布式SQL Server,你值得拥有

介绍
Microsoft SQL Azure 是微软的云关系型数据库,后端存储又称为云 SQL Server(Cloud SQL Server)。
它构建在 SQL Server 之上,通过分布式技术提升传统关系型数据库的可扩展性和容错能力。



数据模型


(1)逻辑模型
云 SQL Server 将数据划分为多个分区,通过限制事务只能在一个分区执行来规避分布式事务。此外,它通过主备复制(Primary-Copy)协议将数据复制到多个副本,保证高可用性。
云 SQL Server 中一个逻辑数据库称为一个表格组(table group),它既可以是有主键的,也可以是无主键的。
这里只讨论有主键的表格组。
如果一个表格组是有主键的,要求表格组中的所有表格都有一个相同的列,称为划分主键(partitioning key)。

云 SQL Server 数据模型

图中的表格组包含两个表格,顾客表(Customers)和订单表(Orders),划分主键为顾客 ID(Customers 表中的 Id 列)。

划分主键不需要是表格组中每个表格的共同唯一主键。图中,顾客 ID 是顾客表的唯一主键,但不是订单表的唯一主键。

同样,划分主键也不需要是每个表格的聚集索引,订单表的聚集索引为组合主键 <顾客 ID,订单 ID> (<Id, Oid>)。

表格组中所有划分主键相同的行集合称为行组(row group)。顾客表的第一行以及订单表的前两行的划分主键均为 30,构成一个行组。

云 SQL Server 只支持同一个行组内的事务,这就意味着,同一个行组的数据逻辑上会分布到同一台服务器。

如果表格组是有主键的,云 SQL Server 支持自动地水平拆分表格组里的表格并分散到整个集群。同一个行组总是分布在同一台物理的 SQL Server 服务器,从而避免了分布式事务。

这种的做法是避免了分布式事务的两个问题:
阻塞

性能
。当然,也限制了用户的使用模式。只读事务可以跨多个行组,但事务隔离级别最多只支持读已提交(read-committed)。


(2)物理模型
在物理层面,每个有主键的表格组根据划分主键列有序地拆分成多个数据分区(partition)。这些分区之间互相不重叠,并且覆盖了所有的划分主键值。这就意味着每个行组属于一个唯一的分区。
分区是云 SQL Server 复制、迁移、负载均衡的基本单位。每个分区包含多个副本(默认为3),每个副本存储在一台物理的 SQL Server 上。
由于每个行组属于一个分区,这也就意味着每个行组的数据量不能超过分区允许的存储上限,也就是说单台 SQL Server 的容量上限。
一般来说,同一个交换机或者同一个机架的机器同时出现故障的概率较大,因而它们属于同一个故障域(failure domain)。
云 SQL Server 保证每个分区的多个副本分布到不同的故障域。每个分区有一个副本为主副本(Primary),其他副本为备副本(Secondary)。
主副本处理所有的查询,更新事务并以事务日志的形式(类似数据库镜像的方式)将事务同步到备副本。各副本接收主副本发送的事务日志并应用到本地数据库。备副本支持读操作,可以减轻主副本的压力。


如图所示,有四个逻辑分区 PA,PB,PC,PD,每个分区有一个主副本和两个备副本。例如,PA 有一个主副本 PA_P 以及两个备副本 PA_S1 和 PA_S2。

每台物理 SQL Server 数据库混合存放了主副本和备副本。如果某台机器发生故障,它上面的分区能够很快地分散到其他活着的机器上。
分区划分是动态的,如果某个分区超过了允许的最大分区大小或者负载太高,这个分区将分裂为两个分区。
假设分区 A 的主副本在机器 X,它的备副本在机器 Y 和 Z。如果分区 A 分裂为 A1 和 A2,每个副本都需要相应地分裂为两段。
为了更好地进行负载均衡,每个副本分裂前后的角色可能不尽相同。例如,A1 的主副本仍然在机器 X,备副本在机器 Y 和机器 Z,而 A2 的主副本可能在机器 Y ,备副本在机器 X 和机器 Z。



架构
云 SQL Server 分为四个主要部分:SQL Server 实例、全局分区管理器、协议网关、分布式基础部件,如图所示。


各个部分的功能如下:
每个 SQL Server 实例是一个运行着 SQL Server 的物理进程。每个物理数据库包含多个子数据库,它们之间互相隔离。子数据库是一个分区,包含用户的数据以及 schema 信息。
全局分区管理器(Global Partition Manager)维护分区映射表信息, 包括每个分区所属的主键范围, 每个副本所在的服务器, 以及每个副本当前的状态,状态包括:副本当前是主还是备,前一次是主还是备,正在变成主,正在被拷贝,或者正在被追赶。
当服务器发生故障时,分布式基础部件检测到后会将这些信息同步到全局分区管理器。全局分区管理器接着执行重新配置操作。另外,全局分区管理器监控集群中 SQL Server 的工作状态,执行负载均衡、副本拷贝等管理操作。
协议网关(Protocol Gateway)负责将用户的数据库连接请求转发到相应的主分区上。协议网关通过全局分区管理器获取分区所在的 SQL Server 实例,后续的读写事务操作都会在网关与 SQL Server 实例之间进行。
分布式基础部件(Distributed Fabric)用于维护机器上下线状态,检测服务器故障并为集群中的各种角色执行选举主节点操作。它在每台服务器上都运行了一个守护进程。


复制与一致性
云 SQL Server 采用 “Quorum Commit” 的复制协议,用户数据存储三副本,至少写成功两副本才可以返回客户端成功。如图所示,事务 T 的主副本分区生成事务日志并发送到备副本。


如果事务 T 回滚,主副本会发送一个 ABORT 消息给备副本,备副本将删除接收到的T事务包含的修改操作。如果事务 T 提交,主副本会发送 COMMIT 消息给备副本,并带上
事务提交顺序号(Commit Sequence Number,CSN)

每个备副本会把事务 T 的修改操作应用到本地数据库并发送 ACK 消息回复主副本。如果主副本接收到一半以上节点的成功 ACK(包含主副本自身),它将在本地提交事务并成功返回客户端。
某些备副本可能出现故障,恢复后将往主副本发送本地已经提交的最后一个事务的提交顺序号CSN。如果两者相差不多,主副本将直接发送操作日志给备副本;如果两者相差太多,主副本将首先把数据库快照传给备副本,再把快照之后的操作日志传给备副本。
主副本与备副本之间传送逻辑操作日志,而不是对磁盘物理页的重做和回滚日志。数据库索引及 schema 相关操作(如创建、删除表格)也通过事务日志发送。
副本之间发送事务日志/逻辑操作日志保证各个副本的数据一致性是目前主流方案,包括TiDB, OceanBase也是采用同样的方案。
实践过程中发现了一些硬件问题,比如某些网卡会表现出错误的行为,因此对主备之间的所有消息都会做校验(checksum)。
同样,某些磁盘会出现“位翻转”错误,因此,对写入到磁盘的数据也做校验(checksum)。




容错
如果数据节点发生了故障,需要启动宕机恢复过程。每个 SQL Server 实例最多服务 650 个逻辑分区,这些分区可能是主副本,也可能是备副本。
全局分区管理器统一调度,每次选择一个分区执行重新配置(Reconfiguration)。
如果出现故障的分区是备副本,全局分区管理器首先选择一台负载较轻的服务器,接着从相应的主副本分区拷贝数据来增加副本;

如果出现故障的分区是主副本,首先需要从其他副本中选择一个最新的备副本作为新的主副本,接着选择一台负载较轻的机器增加备副本。
由于云 SQL Server 采用 "Quorum Commit" 复制协议,如果每个分区有三个副本,至少保证两个副本写入成功,主副本出现故障后选择最新的备副本可以保证不丢失数据。
全局分区管理器控制重新配置任务的优先级,否则,用户的服务会受到影响。比如某个数据分片的主副本出现故障,需要尽快从其他备副本中选择最新的备副本切换为主副本;

某个数据分片只有一个主副本,需要优先复制出备副本。 另外,某些服务器可能下线很短一段时间后重新上线,为了避免过多无用的数据拷贝,
这里还需要配置一些策略,比如只有两个副本的状态持续较长一段时间(SQL Azure 默认配置为两小时)才开始复制第三个副本。
全局分区管理器也采用
"Quorum Commit"

现高可用性。它包含七个副本(奇数),同一时刻只有一个副本为主,分区相关的元数据操作至少需要在四个副本上成功。
如果全局分区管理器主副本出现故障,分布式基础部件将负责从其他副本中选择一个最新的副本作为新的主副本



负载均衡
负载均衡相关的操作包含两种:副本迁移以及主备副本切换。新的服务器节点加入时,系统内的分区会逐步地迁移到新节点,
这里需要注意的是,为了避免过多的分区同时迁入新节点,全局分区管理器需要控制迁移的频率,否则系统整体性能会下降。
另外,如果主副本所在服务器负载过高,可以选择负载较低的备副本升级为主副本来提供读写服务。这个过程称为主备副本切换,不涉及数据拷贝。、
影响服务器节点负载的因素包括:读写次数、磁盘/内存/CPU/IO 使用量等。全局分区管理器会根据这些因素计算每个分区及每个 SQL Server 实例的负载。



多租户
云存储系统中多个用户的操作相互干扰,因此需要限制每个 SQL Azure 逻辑实例使用的系统资源:

  • 操作系统资源限制,比如 CPU、内存、写入速度等等。如果超过限制,将在 10 秒内拒绝相应的用户请求;
  • SQL Azure 逻辑数据库容量限制。每个逻辑数据库都预先设置了最大的容量,超过限制时拒绝更新请求,但允许删除操作;
  • SQL Server 物理数据库数据大小限制。超过该限制时返回客户端系统错误。


总结
Microsoft SQL Azure 基于 SQL Server,通过分布式技术提升了数据库的可扩展性和容错能力。采用主备复制和分区机制,保证数据的高可用性和一致性。
系统通过全局分区管理、负载均衡和资源限制来优化性能并确保多租户环境下的稳定运行。
SQL Server是目前比较主流并且有竞争力的产品,根据最新可靠消息,SQL Server 2025版本会内置SQL Azure 的分布式功能,再加上向量数据库和AI功能,将会世界舞台上具备更强大的竞争力。



参考文章
https://azure.microsoft.com/en-us/products/azure-sql/
https://link.springer.com/chapter/10.1007/978-1-4842-9225-9_2
https://www.sqlshack.com/azure-sql-database-connectivity-architecture/
https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/n-tier/multi-region-sql-server
https://subscription.packtpub.com/book/data/9781789538854/1/ch01lvl1sec08/azure-sql-database-architecture



加入我们的微信群,与我们一起探讨数据库技术,以及SQL Server、 MySQL、PostgreSQL、MongoDB 的相关话题。
微信群仅供学习交流使用,没有任何广告或商业活动。

本文版权归作者所有,未经作者同意不得转载。