杂项4

lambda式中对于变量要求是final的（不可被修改）(无法理解)

就是据变量必须是未进行修改的，比如

class Example {
    private Long instanceId; // 实例变量 - 可在 Lambda 中修改
    private static Long staticId; // 静态变量 - 可在 Lambda 中修改
    
    void process(Long paramId) { // 方法参数 - 隐式 final
        Long localId = null; // 局部变量 - 受限制
        
        localId = 123L; // 修改局部变量
        
        // Lambda 表达式
        Runnable task = () -> {
            instanceId = 456L; // ✅ 允许修改实例变量
            staticId = 789L; // ✅ 允许修改静态变量
            // localId = 999L; // ❌ 禁止修改局部变量
            // paramId = 000L; // ❌ 禁止修改方法参数
        };
    }
}

1. 依赖 ≠ 加载
   引入模块只保证代码在类路径
2. spring.factories = 加载门票
   决定哪些配置类会被考虑
3. 条件注解 = 安全阀
   控制配置类是否真正生效
4. 缺少条件注解 = 定时炸弹
   当类依赖缺失时必然爆炸

通过正确使用条件注解，可以确保：

• MVC 配置只在传统 Web 应用生效
• WebFlux 配置只在网关生效
• 通用组件在所有环境可用
• 各微服务技术栈和平共处

.taz文件使用的方式

你上传的 .tar 文件是 docker save 创建的，它是一个封装了完整 Docker 镜像结构（多层+元数据+标签）的特殊归档文件。它的目的是分发和备份整个 Docker 镜像。

• tar -xzvf (解压缩)： 适用于普通的文件或源代码压缩包，目的是获取里面的文件进行操作。
• docker load： 是唯一正确处理 docker save 生成的 .tar 文件的方法。它的目的是将封装好的完整镜像导入到 Docker 引擎，使其立即可用于运行容器。解压这个特定的 .tar 文件会破坏其结构，导致 Docker 无法识别和使用它。

对于锁用户id的问题

示例    Long id

使用synchronized  必须要是对象，所以必须是包装类型，不能是long类型

synchronized （id）会存在常量池的问题，如果超过，对于Long类型，如果值在-128到127之间（默认情况下），会使用缓存（即同一个值返回同一个对象），但是超出这个范围，每次new Long()会创建新的对象。

- 例如：
Long a = 100L; // 在缓存范围内，同一个对象 Long b = 100L; 
// a == b 为true 
Long c = 200L; Long d = 200L;
// c == d 为false（因为200超出了缓存范围）

超出范围会导致锁失效（不同的对象）

直接使用userId.toString()也是不行，每次的对象都不同？？ 导致无法锁住

userId.intern() 不行（intern（）是string特有的方法）

解决方案：`userId.toString().intern()` 可以确保对于相同的用户id字符串，`intern()` 方法返回的是字符串常量池中的同一个字符串对象。这样，无论有多少个线程，只要用户id相同，它们都会锁定在同一个字符串对象上。（一种解决方案）

悲观锁针对单资源（如数据库行）的竞争，无论单线程或多实例；
分布式锁针对跨系统资源的全局协调，核心是多实例/多进程的互斥管理。

单例，多实例

1. 看竞争资源：

• 资源是数据库里的一行数据？ -> 优先考虑数据库悲观锁 (行锁)。
• 资源是一个文件、一个外部API配额、一段复杂业务逻辑、或者需要跨库操作？ -> 必须用分布式锁。

2. 看协调范围：

• 只需要保证单个数据库写操作的原子性和隔离性？ -> 数据库悲观锁足够。
• 需要保证一系列操作 (可能跨多个SQL、服务、资源) 作为一个整体原子执行？ -> 必须用分布式锁。

3. 多实例 vs 数据库：

• 多个实例操作同一个数据库 -> 对于纯粹且简单的数据库操作竞争，悲观锁 (行锁) 是首选高效方案。
• 多个实例操作不同数据库 -> 悲观锁失效，必须用分布式锁。
• 多个实例操作同一个数据库，但竞争涉及复杂逻辑链 -> 必须用分布式锁。

简单决策树（简化版）：

text

需要协调多个实例访问共享资源吗？
  |
  |--> 资源是数据库里的一行/表，且操作是简单直接的数据库操作 (如单个UPDATE)?
        |
        |--> YES: 使用数据库悲观锁 (行锁/表锁) -> 高效，原生支持。
        |
        |--> NO: (资源是文件/API/复杂逻辑链/跨库操作)
               |
               |--> 使用分布式锁 -> 跨实例协调，保护任意资源或逻辑。

总的来说：单个数据源用悲观锁足以，多个数据源（数据库）要用分布式锁