pipo's site

Spring 中的 Bind

Thu, 22 Jan 2026 14:44:35 +0800

Bind 是什么？

Spring Boot 的 Bind 机制主要负责将 外部配置（如 application.yml、application.properties、环境变量等）绑定到 Java 对象 中。

外部配置绑定优先级：

命令行参数（java -jar app.jar --db.port=9000)
操作系统环境变量（export DB_PORT=9000)
jar 包外部的配置文件（/config/application.yaml)
jar 包内部的配置文件（resources/application.yml)

三种绑定方式

@Value

@Component
public class MyService {
    
    @Value("${app.name:default-app}")  // 支持默认值
    private String appName;
    
    @Value("${app.feature.enabled:false}")
    private boolean featureEnabled;
    
    @Value("#{systemProperties['user.home']}")  // SpEL 表达式
    private String userHome;
}

限制：

不支持 JSR-303 校验
不支持复杂对象绑定
不支持松散绑定
无法在配置文件中提示 IDE 支持

@ConfigurationProperties

@ConfigurationProperties( prefix = "") 外部配置文件：

myapp:
  name: 'myapp'
  server:
    host: 1.1.1.1
    port: 80
  security:
    username: admin
    password: 123

配置方式

@Data
@Component 
@ConfigurationProperties(prefix = "myapp")
public class MyAppProperties {
	// 必须要提供 getter setter，可以使用 Lombook 简化
	private String name;
	
	private ServerConfig server;
	
	private ServerSecurity security;
	
	//嵌套配置 创建类， 必须是 public static
	@Data
	public static class ServerConfig {
		private String host;
		private Long port;
	}
	
	@Data 
	public static class ServerSecurity {
		private String username; 
		private String password;
	}
	
}

使用方式

@Configuration
public class AppConfig {
	@Autowired
	private MyAppProperties properties;
}

prefix 的使用： prefix 填入要被装载的属性的前缀，如果有多个嵌套则可以 myapp.server.XXX.XXX 来装载对应层级下的属性
松散绑定： Spring 可以自动将配置属性的名词与定义的类中的名称进行自动映射支持的类型名称：
- kebab-case (烤肉串式): 全小写，单词间用连字符分隔，如 my-variable-name
- snake_case (蛇形): 全小写，单词间用下划线分隔，如 my_variable_name
- UPPERCASE (全大写): 全部大写，通常用于常量，如 MY_CONSTANT

JSR-303 校验：在类上添加 @Validated 开启校验

@NotNull
@Min()
@Max()
@NotBlank
@Email
@Size(min = )

@Data
@Component
@ConfigurationProperties(prefix = "myapp")
@Validated // <--- 开启第一层校验
public class MyAppProperties {
    @Valid // <--- 关键！告诉 Spring 钻进去校验内部属性
    private ServerConfig server;
    // ...
}

Binder API

使用 Binder API 读取 Environment 中的配置

Bind bind = Binder.get(environment);

读取单个值

// 读取单个值
String host = bind.bind("myapp.server.host", String.class).orElse("1.1.1.1");

读取单个值要写入完整的路径，并且使用点号分割

读取复杂类型 (List/Map)

如果在 application.yaml 里写了一个 List：

my-app:
  whitelist:
    - 192.168.1.1
    - 10.0.0.1

需要使用 Bindable 包装器处理范型

List<String> ips = 
binder.bind( "my-app.whitelist", Bindable.listOf(String.class) // <--- 关键！告诉 Binder 这是一个 List<String> ).orElse(Collections.emptyList());

如果是更复杂的比如

routes:  
  - id: "order-service"  
    path: "/api/order"  
    url: "http://localhost:8081"  
  - id: "user-service"  
    path: "/api/user"  
    url: "http://localhost:8082"
    
private List<Map<Object, Object>> routes = new ArrayList<>();

1.方法一
@SuppressWarnings("unchecked")  
List<Map<Object, Object>> routes = (List<Map<Object, Object>>) (List<?>)  
        binder.bind("gateway.routes", Bindable.listOf(Map.class))  
                .orElse(List.of());
2.方法二                  
List<?> routes = binder.bind("gateway.routes", Bindable.listOf(Map.class))  
        .orElse(List.of());

3.方法三
public class RouteConfig {
    private String id;
    private String path;
    private String url;
}

List<RouteConfig> routes = binder.bind("gateway.routes", 
        Bindable.listOf(RouteConfig.class))
        .orElse(List.of());

读取整个配置类

//后面的 XXX.class 是在告诉 “我要读取的是什么类型的配置请转换成这种类型 "
MyAppProperties properties = bind.bind("myapp", MyAppProperties.class).get();

创建本地 bind 并绑定

创建本地 bind 并添加配置

Binder binder = Binder.get(environment);

//添加 配置
1. 方法一
	MapConfigurationPropertySource source1 = new MapConfigurationPropertySource(map1);
	MapConfigurationPropertySource source2 = new MapConfigurationPropertySource(map2);
	
	Binder localBind = new Binder(source1, source2);
2. 方法二
	List<ConfigurationPropertySource> sources = new ArrayList<>();
	sources.add(new MapConfigurationPropertySource(map1));
	sources.add(new MapConfigurationPropertySource(map2));
	sources.add(new MapConfigurationPropertySource(map3));

	Binder localBind = new Binder(sources);

生产中建议

private Binder createLocalBinder(Map<String, Object>... configMaps) {
    List<ConfigurationPropertySource> sources = new ArrayList<>();
    
    for (Map<String, Object> map : configMaps) {
        if (map != null && !map.isEmpty()) {
            sources.add(new MapConfigurationPropertySource(map));
        }
    }
    
    return new Binder(sources);
}
// 使用
Binder localBind = createLocalBinder(legacyMap, otherMap, thirdMap);

将 bind 中的值绑定类

//RouteDefinition.java
@Data  
public class RouteDefinition {  
    private String id;  
  
    private String path;  
  
    private String url;  
}

Map<String, Object> legacyMap = new HashMap<>();  
legacyMap.put("id", "legacy-service-999");  
legacyMap.put("path", "/api/old");  
legacyMap.put("url", "http://192.168.1.100");  

//Bind 无法直接绑定 Map 需要转换
MapConfigurationPropertySource legacyConfigurationMap = new MapConfigurationPropertySource(legacyMap);  
Binder localBind = new Binder(legacyConfigurationMap);  

									//为什么这里是 "" 空字符串？
RouteDefinition legacyRoute = localBind.bind("", RouteDefinition.class).orElse(new RouteDefinition());  
System.out.println(legacyRoute);

prefix + 要注入的字段名 = key 此时 key 与字段名完全相同，所以使用空字符串如果 legacyMap 中 put 时 key 是 legacy.route.id 那么在将 source 中的属性绑定到 RouteDefinition 时 prefix = “legacy.route”

三种绑定方式对比

特性	@Value	@ConfigurationProperties	Binder API
使用场景	1-2 个简单配置	结构化配置、多个相关配置	动态绑定、运行时绑定
JSR-303 校验	❌ 不支持	✅ 支持（@Validated）	✅ 支持
松散绑定	❌ 不支持	✅ 支持	✅ 支持
复杂对象	❌ 不支持	✅ 支持（嵌套对象）	✅ 支持
IDE 元数据支持	❌ 无提示	✅ 有提示（spring-configuration-metadata.json）	❌ 无提示
类型安全	⚠️ 编译时不检查	✅ 强类型检查	✅ 强类型检查
集合类型	⚠️ 需要手动解析	✅ 自动绑定 List/Set/Map	✅ 自动绑定（需要 Bindable）
默认值	✅ `${prop:default}`	✅ 字段初始化或 @DefaultValue	✅ `.withDefaultValue()`
灵活性	低	中	高

优先使用 @ConfigurationProperties - 类型安全、IDE 支持、可校验
简单配置用 @Value - 如端口、开关等单个属性
动态配置用 Binder API - 如从数据库、Nacos 读取配置后绑定

Reference

从 Future 到 CompletableFuture

Mon, 29 Dec 2025 15:37:35 +0800

使用 Future 完成多线程任务（ThreadPoolExecutor）

快速上手

创建线程池

ThreadPoolExecutor executor = new ThreadPoolExecutor(10, 20, 30, TimeUnit.SECONDS, queue, Executors.defaultThreadFactory());

完成多线程任务要执行的逻辑

// 创建一个新的类 实现 Callable 接口中的 call() 方法
public class Task implements Callable<Long> {
	@Override
	public Long call() throws Exception {
		System.out.println("the Thread name is " + Thread.currentThread().getName());
		return System.currentTimeMillis();
		}
}

创建 Future 实例提交任务
```
Future<Long> future = executor.submit(new Task());
```
⚠️ 注意 submit() 只是提交任务到线程池，并非立即执行任务，执行时机由线程池自行决定。

获取返回值

Long res = future.get(); // 阻塞式无限时返回
Long res = future.get(1, TimeUnit.SECONDS); // 阻塞式限时返回

代码实例：

// Task.java
	public class Task implements Callable<Long> {
		@Override
		public Long call() throws Exception {
			System.out.println("the Thread name is " + Thread.currentThread().getName());
			return System.currentTimeMillis();
			}
	}

// main
public static void main(String[] args) {
	BlockingQueue<Runnable> queue = new ArrayBlockingQueue<>(10);
	ThreadPoolExecutor executor = new ThreadPoolExecutor(10, 20, 30, TimeUnit.SECONDS, queue,                 Executors.defaultThreadFactory());
	//提交任务
	Future<Long> future = executor.submit(new Task());
	try {

		try {
			//阻塞式限时 1s 获取返回值
			System.out.println("the return value is " + future.get(1, TimeUnit.SECONDS));	
		} catch(TimeoutException e) {
		//超时取消任务
			future.cancel(true);
		} catch (ExecutionException e) {
			System.err.println("Task failed: " + e.getCause());
		} catch (InterruptedException e) {
			Thread.currentThread().interrupt();
			System.err.println("Main thread interrupted");
		}

	//关闭线程池	
	} finally {
		executor.shutdown(); // 禁止新任务
		try {
			// 等待已提交任务完成
			if (!executor.awaitTermination(5, TimeUnit.SECONDS)) {
			executor.shutdownNow(); // 取消正在执行的任务
			}
		} catch (InterruptedException e) {
			executor.shutdownNow(); // 被中断时强制关闭
			
			// 为什么要恢复中断状态？
		    // 因为 catch 住异常后，中断标志被清除了
		    // 如果上层代码也想知道 "发生过中断"，必须重新设置
			Thread.currentThread().interrupt(); // 恢复中断状态
		}
	}
	
	
	}

几个注意点

cancel(boolean mayInterruptIfRunning) 向任务发送 Thread.interrupt() 只有任务能够响应中断才有效

当 bool 为 false 时不中断当前正在执行的任务，只暂停未开始执行的任务
当 bool 为 true 时会中断当前正在执行的任务通用写法：

public Long call() throws Exception {
	while (!Thread.currentThread().isInterrupted()) { //
		try {
		//注意：这不是修改上面的 Task，而是展示一个通用写法。
		//  Task 瞬间执行完毕而且 return 不会循环检查，没有响应中断。
		// 在该例中不会被中断，因为没有可中断阻塞点和循环检查
			System.out.println("the Thread name is " + Thread.currentThread().getName());
			return System.currentTimeMillis();

		} catch(InterruptedException e) {
			Thread.currentThread().interrupt();
			System.err.println("thread interrupted");
		}
	}
}

可中断阻塞点是什么？调用 thread.interrupt() 会：将该线程的中断状态（interrupt status）设置为 true。如果线程正处于 sleep()、wait()、join() 等阻塞状态，会立即抛出 InterruptedException，并清除中断状态（变回 false）。

如何优雅关闭线程池

明晰 executor.shutdownNow() 与 executor.shutdown()

方法	shutdown()	shutdownNow()
线程池状态变化	不允许新任务提交，但已提交的任务继续执行	不允许新任务提交，且试图停止正在执行的任务
新任务提交	拒绝（抛出 RejectedExecutionException）	拒绝（抛出 RejectedExecutionException）
正在执行的任务	允许正常执行完成	尝试中断（调用 thread.interrupt()）
等待队列中的任务	会继续执行（队列任务会逐个取出执行）	不执行，直接从队列中移除并返回
中断行为	只中断空闲的线程（interruptIdleWorkers()）	中断所有工作线程（interruptWorkers()）
返回值	void（无返回值）	List ：返回队列中尚未开始执行的任务列表
适用场景	希望程序正常结束，不丢失任何已提交的任务	需要尽快停止，愿意牺牲队列中的任务
是否会等待任务结束	是（线程池会等到所有任务执行完才彻底终止）	否（立即尝试停止）

四步走关闭线程池：
1. 先优雅关闭 `shutdown()` 放在最外层，确保执行
2. 等待一定时间 `if(!executor.awaitTermination(5, TimeUnit.SECONDS))` 
3. 时间到后强行关闭 `shutdownNow()`
4. 包裹 2-3 catch 中断异常，防止意外退出未关闭线程池

实战示例

多线程并发执行任务 思路：

创建数组或 list
将任务通过 for 循环提交到线程池中
查看结果

框架:

//1.创建线程池
//2.创建待执行的任务队列 
List<Future<Long>> futures = new ArrayList<>();

try {
	//将任务提交到线程池
	for (int i = 0; i < n; i++) {
		futures.add(executor.submit(new Task()));	
	}
	for (Future<Long> future : futures) {
		//查看结果
	}
} finally {
	//关闭线程池
}

操作	关键代码	备注
定义任务	implements Callable	有返回值，能抛异常
提交任务	Future f = exec.submit(task)	异步，不阻塞
获取结果	f.get(1, TimeUnit.SECONDS)	阻塞，建议设超时
取消任务	f.cancel(true)	需要任务代码配合响应中断
大忌	在 submit 循环中直接 get	会变成串行

使用现代的 CompletableFuture 完成多线程任务

快速上手

创建线程池
创建逻辑（与 Future 不同，要实现 Supplier 接口的 get() 方法）
使用 CompletableFuture 提交任务
添加你要的操作代码实例：

try (ThreadPoolExecutor executor = new ThreadPoolExecutor(10, 20, 30, TimeUnit.SECONDS, queue, Executors.defaultThreadFactory())) {
	CompletableFuture<Long> cf = CompletableFuture.supplyAsync(new CFTask(), executor); 
	Long long1 = cf.join();
	System.out.println(long1);
} catch (Exception e) {
	// close thread pool
}

supplyAsync() 异步非阻塞提交任务

方法	阻塞？	异常处理
`get()`	✅ 阻塞	抛 checked exception（必须 try-catch）
`join()`	✅ 阻塞	抛 unchecked `CompletionException`（可不 catch）

常见的几种方法

创建异步任务


方法	作用	例子
supplyAsync(Supplier, Executor)	指定线程池执行，返回有结果的异步线程	cf = CompletableFuture.supplyAsync(() -> dbQuery(), myExecutor);
runAsync(Runnable, Executor)	无返回值异步任务，指定线程池	CompletableFuture.runAsync(() -> sendEmail());

supplyAsync 异步执行要有返回值，被执行的任务要去实现 Supplier 接口
runAsync 异步执行但无返回值，要实现 Runnable 接口

转换结果（链式处理的核心）

方法	作用	例子
thenApply(fn)	获取上一方法的返回值并执行逻辑，再次返回	.thenApply(user -> user.getName())
thenApplyAsync(fn)	异步转换（新线程）	常用
thenCompose(fn)	上一步返回另一个 CF → 扁平化（避免嵌套）	.thenCompose(id -> getOrderCF(id))
thenComposeAsync(fn)	异步扁平化	常用

thenApply vs thenCompose：

thenApply：函数返回普通值
thenCompose：函数返回 CompletableFuture（必须用这个才能链下去不嵌套）

消费结果（只关心结果，不返回新值）

方法	作用	例子
thenAccept(result -> …)	拿到结果处理（比如打印、存库）	.thenAccept(pname -> System.out.println(pname))
thenAcceptAsync(…)	异步消费
thenRun(() -> …)	不关心上一步结果，只做后续动作	.thenRun(() -> {System.out.println(“flushing”);}

异常处理

方法	作用
exceptionally(ex -> defaultValue)	出异常时返回备用值（继续链）
handle((result, ex) -> …)	无论正常还是异常都能处理，最灵活
whenComplete((result, ex) -> …)	只观察，不改变结果（常用于日志）
推荐优先用 handle 或 exceptionally。

两个任务组合

方法	作用
thenCombine(otherCF, (r1, r2) -> newResult)	两个任务都完成 → 合并结果
thenCombineAsync(…)	异步合并
thenAcceptBoth(otherCF, (r1, r2) -> …)	两个完成 → 消费，不返回
runAfterBoth(otherCF, () -> …)	两个完成 → 执行动作

多个任务全部完成

方法	作用
CompletableFuture.allOf(cf1, cf2, cf3…)	等待所有任务完成，返回 void 的 CF
CompletableFuture.anyOf(cf1, cf2…)	哪个最快完成就返回那个结果
等待 n 个任务方式：
`CompletableFuture.allof(futures.toArray(CompletableFuture[]::new)).join();` 或者
`CompletableFuture.allof(futures.toArray(CompletableFuture[0])).join();`

为什么要加 join()? 为了 阻塞等待所有任务完成, 如果不加 join 他会异步执行后续代码，未等待所有线程完成。

实战示例

练习 supplyAsync (发起) thenApply (加工) thenCombine(合并) exceptionally（异常处理） thenAccept (最终消费) 已有

    public static String queryDB(String queryName);
    public static String unsafeApi()

目标：

使用 queryDB 查询 username 查到结果后加入前缀 “Proccessed_”, 打印
使用 queryDB 查询 UserStats 和 OrderCounts 完成后组合结果合并成一个字符串 “UserStats + OrderCounts” 并打印
调用 unsafeApi() 如果发生错误，进行处理并且返回默认值 “Default_Safe_Data”

//task.1
CompletableFuture.supplyAsync(() -> 
					queryDB("username"), executor) //{ return queryDB("username");} 
					//此处加入 executor，后续会自动沿用这个线程，如果不使用 executor 会使用 forkjoinpool
				.thenApply(res -> { 
				//自己命名接收到的值然后进行处理
					return "Proccessed_" + res;
				})
				.thenAccept(name -> {
					System.out.println(name);
				});


//task.2
CompletableFuture<String> cf1 = CompletableFuture.supplyAsync(() -> queryDB("UserStats"), executor);
CompletableFuture<String> cf2 = CompletableFuture.supplyAsync(() -> queryDB("OrderCounts"), executor);
cf1.thenCombine(cf2, (cf1, cf2) -> { // thenCombine 会自动等待两个任务完成，不需要加 join() 或 get() 来强制等待
	return cf1 + ": " + cf2; 
})
.thenAccept(combined -> {
log("合并报表: " + combined); 
});
CompletableFuture.supplyAsync(() -> queryDB("UserStats"), executor).thenCombine()

//task.3
CompletableFuture.supplyAsync(() -> unsafeApi(), executor)
		.exceptionally((error) -> {
            log("error: " + error.getMessage());
            return "Default_Safe_Data";
        })
        .thenAccept(data -> System.out.println(data));

⚠️ 注意

thenApply 必须返回对象，不能是 void（比如只 println 不 return）。

异步异常必须处理，否则链会断掉

练习 allOf(Future… cfs) （聚合多任务）， completeOnTimeout() (超时控制) 已有
```
public static double fetchPrice(String platform);
public static List<Double> batchQuery(List<String> platforms){}
```
目的：
- 在 batchQuery() 中并发查询所有 platform
- 查询时长超过 2s 与错误的返回 -1
- 等待所有任务完成后，获取数据返回 List<Double>

public static List<Double> batchQuery(List<String> platforms) {

        ExecutorService executor = Executors.newFixedThreadPool(platforms.size());
        Double defaultValue = -1.0;
        List<Double> result = new ArrayList<>();
        try {
            List<CompletableFuture<Double>> futures = new ArrayList<>(); //创建数组用来查询和接收 N 个平台的数据

            for (String platform : platforms) { 
                futures.add(CompletableFuture.supplyAsync(() -> fetchPrice(platform), executor)
                        .exceptionally((e) -> {
                            System.err.println(platform + "  " + e.getMessage());
                            return -1.0; //报错，将异常吞掉，返回 -1 作为默认值
                        }).completeOnTimeout(defaultValue, 2, TimeUnit.SECONDS)); //(返回值， 时间， 单位)
            }
            //这里编排 有一些讲究
            //❌ ~~如果 completeOnTimeout 在 exceptionally 前，exceptionally 会接收到超时的报错~~ 
			//✅ exceptionally：会吞掉真实的异常，返回正常值。 
			// completeOnTimeout：不会抛异常，但它吞掉的不是“异常”，而是“超时未完成”的状态，直接转为正常完成 + 默认值。
			
			
			//⚠️ 着重 必须加 join 存放任务方式是 cf.toArray(CompletableFuture []::new)
            CompletableFuture.allOf(futures.toArray(CompletableFuture[]::new)).join();
            for (CompletableFuture<Double> future : futures) {
                result.add(future.join()); // 这里拿真正的结果
            }


            return result;

        } finally {
            executor.shutdown();
            try {
                if (!executor.awaitTermination(5, TimeUnit.SECONDS)) {
                    executor.shutdownNow();
                }
            } catch (InterruptedException e) {
                executor.shutdownNow();
                Thread.currentThread().interrupt();
            }

        }
    }

⚠️ 注意 CompletableFuture.allOf(futures.toArray(CompletableFuture[]::new)).join(); 返回值是 void 需要手动对单个任务获取 completeOnTimeout：不会抛异常，但它吞掉的不是“异常”，而是“超时未完成”的状态，直接转为正常完成 + 默认值。

Reference

ExecutorService (Java SE 17 & JDK 17)

Guide To CompletableFuture | Baeldung

Java基础IO

Sat, 27 Dec 2025 21:47:35 +0800

modified-time: 2026-01-06 21:07:23

字节流和字符流

字符流文件: .txt、.json、.csv、.xml 等
二进制文件（字节流）：图片、视频、.pdf、.docx、.jar 等

本质上都是字节，只是字符流通过字符集编码，二进制文件不能直接当成文本去解码

读写字符流

处理流
- BufferedReader 和 BufferedWriter 处理读取到的文件。
转换流
- 使用 InputStreamReader 和 OutputStreamWriter 将读取到的字节流转换为正确编码的字符流需要指定明确的编码可以直接字符串也可以使用 StandardCharsets.xxx
```
new InputStreamReader(new FileInputStream(inputFile), StandardCharsets.UTF_8 );  
  
new InputStreamReader(new FileInputStream(inputFile), "UTF-8");  
```

为什么不使用 FileReader 和 FileWriter？ new FileReader(filePath) // 内部实际是 new InputStreamReader(new FileInputStream(…), 平台默认编码) 他们内部使用的是当前平台默认编码，无法显式指定读取写入的编码方式。 结论：永远不要用 FileReader / FileWriter，改用 FileInputStream + InputStreamReader（指定编码）

节点流 FileInputStream 和 FileOutputSteam 直接读取

//  示例
try (BufferedReader reader = new BufferedReader(
		new InputStreamReader(new FileInputStream(inputFile), StandardCharsets.UTF_8));
	BufferedWriter writer = new BufferedWriter(
	new OutputStreamWriter(new FileOutputStream(outputFile),StandardCharsets.UTF_8))) {
	// do sth...
	}catch (IOException e) {
		e.printStackTrace();
	}

读写字节流（二进制）

处理流
- BufferedInputStream 和 BufferedOutputStream
- 数据类型读写：DataInputStream、DataOutputStream（读写 int、double 等基本类型）
- 对象序列化：ObjectInputStream、ObjectOutputStream
转换流（因为是二进制文件所以可以不使用转换流）
字节流
- FileInputStream 和 FileOutputStream

//  示例
try (BufferedInputStream reader = new BufferedInputStream(new FileInputStream(inputPath));
	BufferedOutputStream writer = new BufferedOutputStream(new FileOutputStream(outputPath))) {
	// do sth...
	}catch (IOException e) {
		e.printStackTrace();
	}

缓存使用

使用缓存可以手动控制单次读入的数据量可以避免：

如果单行长文本使用 readLine() 可能 GC OOM
如果是多行但换行频率高会不断循环增加网络 RTT 硬盘 IO 等
如果是字节流使用 readAllBytes() 读取大文件也会导致内存被大量占用降低效率甚至 OOM. 使用步骤：

字节流：

byte[] buffer = new byte[81920];
while ((len = reader.read(buffer)) != -1) { 
	writer.write(buffer, 0, len);
}

字符流

char[] buffer = new char[8192];
while ((len = reader.read(buffer)) != -1) { //如果是 readLine 的话用 != null
	writer.write(buffer, 0, len);
}

缓冲区长度陷阱（核心）：
- 注意你的 writer.write(buffer, 0, len)。
- 使用 BufferedInputStream/BufferedReader 时，它们 内部本来就有一层缓冲，默认大小 8KB；
- 思考： buffer 的长度是 81920。如果文件的最后一次读取只剩 100 个字节，那么 len 就会等于 100。
- 如果写成 writer.write(buffer)，程序会将整个 81920 字节全部写入文件，导致 文件末尾多出大量的空白或旧数据残余。这就是为什么要用 len 的原因。

流家族	抽象基类	常见节点流示例	常见处理流示例
字节流	InputStream / OutputStream	FileInputStream / FileOutputStream	BufferedInputStream / BufferedOutputStream, DataInputStream / DataOutputStream, ObjectInputStream / ObjectOutputStream
字符流	Reader / Writer	FileReader / FileWriter	BufferedReader / BufferedWriter, InputStreamReader / OutputStreamWriter

RandomAccessFile

用于解决无法随机访问读写的问题而诞生，但因为其比较底层，现在被 FileChannel + MappedByteBuffer 代替

RAF 的本质： 它是一个带“指针（File Pointer）”的状态机。
并发冲突点： 指针是共享资源。多线程必须通过 new 多个 RAF 实例来实现“逻辑上的无状态”，或者在单实例下使用 synchronized（但会退化为单线程）。

如何使用

// 创建
RandomAccessFile raf = new RandomAccessFile(inputPath, mode); 
//基础读写
raf.read(buffer);
raf.write(buffer, start, end);

//获取文件长度与申请空间
raf.length();
raf.setLength();
// 预分配是防止文件碎片化和频繁扩容的关键

//刷盘
raf.getFD.sync();

❓ 提问：

为什么这里不需要向上面一样包装 BufferedInput/OutputStream？

BufferedOutputStream 的存在是为了给那些“一次只写一个字节/少量字节”，进行缓冲减少频繁直接调用 native 方法写入。它在内存里开辟一个 8KB 的数组，凑够了再调一次系统内核（System Call）。
为什么要避免多次直接调用系统内核去写入？

调用系统内核需要从用户态转变为内核态，该过程耗费大量时间会消耗 CPU 周期，要减少不必要的损耗。这也就是为什么在非强一致性操作中常使用 raf.getFD.sync() 而不使用 RandomAccessFile(inputPath, "rwd/rws");
为什么要刷盘？

write() 成功不代表数据落盘，只代表数据进入了内核缓存。
如果我在 FileOutputStream 套了 BufferedputStream 我每次读取少量数据后就 write 是否会让其失效？

只要 buffer 没满、没手动 flush、没 close，数据就停留在用户态的 byte [] 数组里，不触发系统调用。

触发时机	是否切换内核态
write(b) 但 buffer 未满	❌ 否，纯内存操作
write(b) 导致 buffer 满了	✅ 是，自动调用底层 write
手动调用 flush()	✅ 是
调用 close()	✅ 是（内部先 flush）

实战示例（多线程复制文件）

要求:

使用 RAF 读取原数据获取长度，预分配空间，为每个子线程分配任务
使用线程池和 CompletableFuture 完成子线程调用与任务执行
使子线程只工作在自己被分配到的区间内

try (RandomAccessFile raf = new RandomAccessFile(input, "rw")) {
            //获取长度，为预分配空间和切片做准备
            long length = raf.length();
            //根据线程数量切片
            long splitSize = length / 16;
            //分配空间后写入刷盘
            raf.setLength(length);
            raf.getFD().sync();
            ThreadPoolExecutor executor = threadpool();

            try {
                List<CompletableFuture<String>> cf = new ArrayList<>();
				
				//步长为每个子线程获得的工作量
                for (long i = 0; i < length; i += splitSize) {

                    if (i > length) {
                        break;
                    }
                    long start = i;
                    //如果剩余数据不足分片大小，则只设置剩余大小
                    long end = i + splitSize > length ? length : i + splitSize;
                    cf.add(CompletableFuture.supplyAsync(() -> singleCopy(new Task(start, end, input, output)),
                            executor));

                }

                CompletableFuture.allOf(cf.toArray(CompletableFuture[]::new)).join();
            } finally {
                executor.shutdown();
                try {
                    if (!executor.awaitTermination(5, TimeUnit.SECONDS)) {
                        executor.shutdownNow();
                    }
                } catch (InterruptedException e) {
                    executor.shutdownNow();
                    Thread.currentThread().interrupt();
                }
            }

        }
    }

class Task {
    public long startOffset;
    public long endOffset;
    public String inputPath;
    public String outputPath;
   


    public Task(long startOffset, long endOffset, String inputPath, String outputPath) {
        this.startOffset = startOffset;
        this.endOffset = endOffset;
        this.inputPath = inputPath;
        this.outputPath = outputPath;

    }

}
public static String singleCopy(Task task) {
        try (RandomAccessFile read = new RandomAccessFile(task.inputPath, "r");
                RandomAccessFile target = new RandomAccessFile(task.outputPath, "rw")) {
            //设置读取和写入的偏移量，也就是开始坐标
            read.seek(task.startOffset);
            target.seek(task.startOffset);
            
            int len;
            byte[] buffer = new byte[81920];
            //使用局部变量记录当前读取到的位置
            long currentPos = task.startOffset;
            while (currentPos < task.endOffset) { 
	            //如果剩余量小于 buffer 里读取到的长度，则只读取 剩余工作量
	            //避免污染其他线程的工作区间
                long remaining = task.endOffset - currentPos;
                int maxRead = (int) Math.min(buffer.length, remaining);

                len = read.read(buffer, 0, maxRead);
                if (len == -1) {
                    break;
                }
                target.write(buffer, 0, len);
                currentPos += len;
            }
            target.getFD().sync();
        } catch (FileNotFoundException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        } catch (IOException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
        return "success!";
    }

⚠️ 注意为什么这里不使用 getFilePointer() 去直接获取当前偏移量位置，而是使用局部变量？答案依旧是 getFilePointer() 是用的 native 方法，会从用户态切换到内核态

Reference

跨域

Tue, 16 Dec 2025 15:07:12 +0800

跨域与 CORS

1) 什么是跨域

浏览器判断“是否同源/是否跨域（跨源）”只看 协议 + 域名 + 端口（scheme/host/port）。三者任意一个不同，就是跨域。

http://localhost:8001 → http://localhost:8002：跨域（端口不同）
http://a.com → https://a.com：跨域（协议不同）
http://a.com → http://b.com：跨域（域名不同）

注意：path 不参与跨域判断。
（同源/CORS 概览）https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

2) 请求头是什么

HTTP 请求由「请求行 + 请求头(headers) + 空行 + 可选正文(body)」组成。

请求头：一堆 Key: Value，描述这次请求的“元信息/上下文”，比如：
- Host：要访问哪个站点（虚拟主机选择相关）
- Origin：浏览器自动带的“发起请求的源”（跨域时关键）
- Accept：期望响应的数据类型
- Content-Type：请求 body 的格式（POST/PUT 等常见）
- Authorization：认证信息（常触发预检）

3) CORS 把跨域请求分为两类

核心区别：是否需要 preflight（预检 OPTIONS）。

A. 简单请求（simple request）

跨域情况下满足条件 → 浏览器 直接发送真正请求，不先发 OPTIONS。

简单请求需要同时满足：

方法是：GET / HEAD / POST
你在代码里手动设置的请求头属于“安全白名单”（不展开死背，记住：Authorization、自定义 X-* 往往会让它变非简单）
若是 POST，Content-Type 只能是以下三种之一：
- application/x-www-form-urlencoded
- multipart/form-data
- text/plain

（Simple requests 条件）https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests

简单请求的流程

浏览器发送真正请求（带 Origin）到跨域服务器
服务器返回响应
浏览器检查响应里是否允许该源读取结果：
- 看 Access-Control-Allow-Origin
- 若允许 → JS 能读到响应
- 若不允许/缺失 → 请求可能已到后端，但浏览器不让 JS 读取响应（控制台报 CORS）

重要纠错：Access-Control-Allow-Origin 的值只能是：

* 或者一个 origin（协议+域名+端口），比如 http://localhost:8001
不能带 path https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin

B. 非简单请求（preflighted request）

只要不满足简单请求条件（常见原因：Content-Type: application/json、带 Authorization、方法是 PUT/DELETE 等），浏览器通常会：

先发预检 OPTIONS（preflight），问服务器“我等会儿这样请求行不行？”

预检请求大概长这样：

OPTIONS /api HTTP/1.1
Origin: http://localhost:8001
Access-Control-Request-Method: POST
Access-Control-Request-Headers: authorization, content-type

服务器如果同意，需要在 OPTIONS 的响应 里声明允许，例如：

Access-Control-Allow-Origin: http://localhost:8001
Access-Control-Allow-Methods: POST
Access-Control-Allow-Headers: Authorization, Content-Type

Access-Control-Allow-Headers / Allow-Methods 不要求完全一致
只要它们的允许集合包含预检里声明要用的那些即可（集合“超集”覆盖请求即可；从请求角度看就是“请求需求是允许集的子集/真子集”）。
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#preflighted_requests

通过预检后，浏览器才会发真正请求；预检不通过，真正请求通常不会发出。

Reference

Cross-Origin Resource Sharing (CORS)| MDN Preflight 机制| MDN HTTP 报文结构
 Content-Type

Location匹配

Mon, 15 Dec 2025 11:54:12 +0800

匹配类型

修饰符	含义	示例
`=`	精确匹配	`location = /api`
`^~`	前缀匹配，匹配到就停止	`location ^~ /static/`
`~`	正则匹配（区分大小写）	`location ~ \.php$`
`~*`	正则匹配（不区分大小写）	`location ~* .(jpg\|gif\|png)$
无	普通前缀匹配	`location /api/`

精确匹配

location = /api {
 #.....
}
只有访问是 example.com/api 时才匹配
example.com/api/ ❌
example.com/apis ❌

前缀匹配

location ^~ /api/ {
 #....
}
example.com/api/ ✅
example.com/apis ❌
example.com/api/123456 ✅

正则匹配

location ~*  \.(jpg|gif|png)$ { #\. 是转义 $表示结束

}
example.com/avatar.jpg ✅
exampl.com/logo.svg ❌
example.com/logo.pngDoSomeDangerAction ❌
example.com/thepath/logo.png ✅

优先级

高  ┌─────────────────────┐
    │  =   精确匹配       │
    ├─────────────────────┤
    │  ^~  前缀匹配停止   │
    ├─────────────────────┤
    │  ~   正则（顺序）   │
    │  ~*  正则（顺序）   │
    ├─────────────────────┤
    │  无  最长前缀匹配   │
低  └─────────────────────┘

拼接规则

root & index

root 表示文件路径地址的根目录， index 表示当发送的请求是目录时会去该目录下查找的文件;

index 指令定义了当用户请求一个目录（而不是一个具体文件）时，Nginx 应该默认返回哪个文件;

location / {
 root /var/www/home/;
 index index.html index.htm index.php
}

当进入的请求是 example.com/ 时会匹配到上述 location 匹配段 拆下来 / ，root + / = var/www/home/ 因为查找的是 dir 而非 file ，所以根据 index 从前往后查找对应文件 / + index [1] = /index.html 重新在 conf 里匹配。

因为 /index.html 符合 / 的规则，于是 root + /index.html, 此时访问的是具体的文件，检查是否存在然后返回。

alias

alias 常为改善 root 可能导致的 路径重复问题 而使用。

location /images/ {
	root /var/www/assets/pics/;
	
}

我们请求访问时如果是 example.com/images/img.png 到这里会被拆解拼接 为 /var/www/assets/pics/images/img.png

但我们实际只是 暴露给用户的地址是 images 我们的图片路径并不在这里，此时为了保证 API 的易读性和我们后端资源的有序我们可以使用 alias

location /images/ {
	alias /var/www/assets/pics/;
	
}

拼接结果就是 /var/www/assets/pics/img.png

巨坑

使用精准匹配导致无法托管正确页面

如果我们用精准匹配去设置根目录为欢迎页，会出错

location =/ {
 root /var/www/home/;
 index index.html index.htm index.php
}


1977/12/15 15:45:24 [debug] 332923#332923: *17 http request line: "GET / HTTP/1.1"
1977/12/15 15:45:24 [debug] 332923#332923: *17 http uri: "/"
1977/12/15 15:45:24 [debug] 332923#332923: *17 http args: ""
1977/12/15 15:45:24 [debug] 332923#332923: *17 http exten: ""
1977/12/15 15:45:24 [debug] 332923#332923: *17 http header: "Accept: */*"
1977/12/15 15:45:24 [debug] 332923#332923: *17 http header done
1977/12/15 15:45:24 [debug] 332923#332923: *17 test location: "/avatar/"
1977/12/15 15:45:24 [debug] 332923#332923: *17 test location: "/404.html"
1977/12/15 15:45:24 [debug] 332923#332923: *17 test location: "/"
1977/12/15 15:45:24 [debug] 332923#332923: *17 using configuration "=/"    #使用“=/精准匹配”
1977/12/15 15:45:24 [debug] 332923#332923: *17 open index "/var/www/home/index.html" #检查index.html是否存在
1977/12/15 15:45:24 [debug] 332923#332923: *17 internal redirect: "/index.html?" #内部重定向
1977/12/15 15:45:24 [debug] 332923#332923: *17 rewrite phase: 1
1977/12/15 15:45:24 [debug] 332923#332923: *17 test location: "/avatar/"
1977/12/15 15:45:24 [debug] 332923#332923: *17 test location: "/static/"
1977/12/15 15:45:24 [debug] 332923#332923: *17 test location: "/health" #找不到了因为 /index.html 不匹配 /
1977/12/15 15:45:24 [error] 332923#332923: *17 open() "/etc/nginx/html/index.html" failed (2: No such file or directory), client: 127.0.0.1, server: localhost, request: "GET / HTTP/1.1", host: "localhost:8070" 
1977/12/15 15:45:24 [debug] 332923#332923: *17 http finalize request: 404, "/index.html?" a:1, c:2
1977/12/15 15:45:24 [debug] 332923#332923: *17 http special response: 404, "/index.html?"
1977/12/15 15:45:24 [debug] 332923#332923: *17 internal redirect: "/404.html?"
1977/12/15 15:45:24 [debug] 332923#332923: *17 rewrite phase: 1
1977/12/15 15:45:24 [debug] 332923#332923: *17 test location: "/avatar/"
1977/12/15 15:45:24 [debug] 332923#332923: *17 test location: "/404.html"
1977/12/15 15:45:24 [debug] 332923#332923: *17 using configuration "=/404.html"

解决方案

使用 try_files

try_files 检查文件是否按指定顺序存在，并使用第一个用于请求处理的寻得文件; 处理过程在当前语境下执行。

Checks the existence of files in the specified order and uses the first found file for request processing;

这样就避免了内部重定向
```
location =/ {
 root /var/www/home/;
 try_files /index.html =404 
}
```
将 root 放在全局

admin/ 与 admin 同时跳转同一 index

location /admin {
	alias /var/www/admin/;
	index index.html;
	try_files $uri $uri/index.html =404;
}

Reference

title: "Nginx基础知识从小白到入门"
image: "https://raw.githubusercontent.com/wsgzao/storage-public/master/img/20191113180648.png"
description: "Nginx基础知识从小白到入门"
url: "https://wsgzao.github.io/post/nginx/"
favicon: ""
aspectRatio: "96.79245283018868"

title: "Nginx 快速教程"
image: "https://raw.githubusercontent.com/dunwu/images/master/cs/web/nginx/nginx.jpg"
description: "nginx-tutorial"
url: "https://dunwu.github.io/nginx-tutorial/#/nginx-quickstart"
favicon: ""
aspectRatio: "56.26959247648903"

title: "Nginx 从入门到实践（2023年版）Nginx 简介 Nginx 是什么 nginx (engine x) 是一个  - 掘金"
image: "https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/75209bc63f284481ae19c0c98d41187e~tplv-k3u1fbpfcp-zoom-in-crop-mark:1512:0:0:0.awebp?"
description: "Nginx 简介 Nginx 是什么 nginx (engine x) 是一个 HTTP 和反向代理服务器，一个邮件代理服务器，一个通用的 TCP/UDP 代理服务器，最初由 Igor Sysoev "
url: "https://juejin.cn/post/7223653286464667703#heading-20"
favicon: ""
aspectRatio: "96.18268575323789"

title: "try_files 文档"
image: "https://nginx.org/img/nginx_logo.svg"
description: ""
url: "https://nginx.org/en/docs/http/ngx_http_core_module.html#try_files"
favicon: ""
aspectRatio: "28.666666666666668"

title: "index 文档"
image: "https://nginx.org/img/nginx_logo.svg"
description: ""
url: "https://nginx.org/en/docs/http/ngx_http_index_module.html#index"
favicon: ""
aspectRatio: "28.666666666666668"

Nginx快速入门

Sun, 14 Dec 2025 20:30:12 +0800

安装

导入源（Debian/Ubuntu）

# 安装必要的证书包
sudo apt install curl gnupg2 ca-certificates lsb-release ubuntu-keyring
# 导入 NGINX 官方签名密钥
curl https://nginx.org/keys/nginx_signing.key | gpg --dearmor | sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg >/dev/null
# 添加官方稳定版仓库
echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] http://nginx.org/packages/ubuntu `lsb_release -cs` nginx" | sudo tee /etc/apt/sources.list.d/nginx.list
# 设置官方源的优先级高于 Ubuntu 源
echo -e "Package: *\nPin: origin nginx.org\nPin: release o=nginx\nPin-Priority: 900\n" | sudo tee /etc/apt/preferences.d/99nginx

安装 Nginx 软件包

sudo apt update                        
sudo apt install nginx

启动与配置

sudo systemctl start nginx #启动 Nginx

基本命令

nginx -s stop #强行关闭 
nginx -s quit #优雅关闭
nginx -s reload #重载配置
nginx -t #检查语法问题

检查语法错误与查看配置所在位置

sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

查看配置

user  nginx; #用户
worker_processes  auto;

error_log  /var/log/nginx/error.log notice; #日志地址
pid        /run/nginx.pid; 


events {
    worker_connections  1024; #最大链接线程数
}


http {
    include       /etc/nginx/mime.types; 
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    #gzip  on;

    include /etc/nginx/conf.d/*.conf;  #具体配置位置
}

server {
    listen       80;
    server_name  localhost;

    #access_log  /var/log/nginx/host.access.log  main;

#    location /index {
#        root   /usr/share/nginx/html;
#        index  index.html index.htm;
#    }
	location / { 
	root html; # 网站根目录 
	index index.html index.htm; # 默认首页文件 
	}
    #error_page  404              /404.html;

    # redirect server error pages to the static page /50x.html
    #


    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }

    # proxy the PHP scripts to Apache listening on 127.0.0.1:80
    #


    #location ~ \.php$ {
    #    proxy_pass   http://127.0.0.1;
    #}
    # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
    #


    #location ~ \.php$ {
    #    root           html;
    #    fastcgi_pass   127.0.0.1:9000;
    #    fastcgi_index  index.php;
    #    fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
    #    include        fastcgi_params;
    #}

    # deny access to .htaccess files, if Apache's document root
    # concurs with nginx's one
    #


    #location ~ /\.ht {
    #    deny  all;
    #}
}

快速配置

目标访问 test: 8005 跳转到本地 index.html

修改上面配置为

 listen 8005;
 server_name test;

location / { 
	root /var/www/test;
	 index index.html;
}

sudo mkdir -p /var/www/test/
sudo touch /var/www/test/index.html 
sudo tree /var/www/test/
/var/www/test/
└── index.html

重载配置

> sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
> sudo nginx -s reload

测试链接

> curl -v http://test:8005/
* Could not resolve host: test
* Closing connection
curl: (6) Could not resolve host: test

会发现无法访问原因有二：

当访问 test 时无法解析到对应 ip
选择的位置缺少权限解决方案：

在 hosts 里添加 127.0.0.1 test
赋予 Nginx 执行权限或者转到 /var/www/ 目录下

反代短链接不跳转：上游依赖 Host 头

背景

Nginx 对外监听：www.shortlink.com

反向代理到上游短链服务：nurl.ink

server {
  listen 80;
  server_name www.shortlink.com;

  location / {
    proxy_pass https://nurl.ink;
  }
}

现象

访问 http://www.shortlink.com/xxxx 没有按预期 301/302 跳转（或返回不对/404/落到默认站点）

关键判断

后端识别短码通常看的是“请求里的 Host 头 + path”
通过反代访问时，转发给上游的请求里，Host 往往还是 www.shortlink.com 上游按 Host 做站点路由/短链域名匹配时，就可能“不认这个域名”，所以不跳转。

注意：Host 是请求头（request header），不是“返回的 Host 头”。响应里一般没有 Host。

根因

Nginx 转发到上游时，没有把 Host 改成上游想要的 nurl.ink（或没按上游规则传递）
如果上游是 HTTPS，还可能需要 SNI：没开 proxy_ssl_server_name 会导致 TLS 层选错站点/证书，行为异常。

修复方案

让上游收到正确的 Host（两种写法选一种）：

location / {
  proxy_pass https://nurl.ink;

  # 方案 A：写死上游域名
  proxy_set_header Host nurl.ink;

  # 方案 B：用变量（
  # proxy_set_header Host $proxy_host;

  # 保留原始信息
  proxy_set_header X-Forwarded-Host $host;
  proxy_set_header X-Forwarded-Proto $scheme;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

  
  proxy_ssl_server_name on;
}

验证方法

直连上游看是否会跳转：

curl -I https://nurl.ink/xxxx

走反代看是否和直连一致：

curl -I http://www.shortlink.com/xxxx

如果要确认“Host 造成的差异”，用 curl 人工指定 Host 做对比：

curl -I -H 'Host: nurl.ink' http://127.0.0.1/xxxx
curl -I -H 'Host: www.shortlink.com' http://127.0.0.1/xxxx

Reference

title: "Beginner’s Guide"
image: "https://nginx.org/img/nginx_logo.svg"
description: ""
url: "https://nginx.org/en/docs/beginners_guide.html"
favicon: ""
aspectRatio: "28.666666666666668"

W-TinyLFU

Wed, 10 Dec 2025 00:00:00 +0000

W-TinyLFU

前置理解

SLRU 分段最久未使用

分段的意思是将原来只有一段的队列分成两段，一段为 保护段 另一段为 试用段，其内部逻辑与 LRU 相同。核心流程：

新数据会进入试用段
试用段中的数据再次被访问进入保护段
保护段中被淘汰的数据会回到试用段 SLRU 相比 LRU 的优势 在 LRU 场景下如果短时有大量新的散列的非热点数据访问可能导致缓存中的热点数据被移除替换导致 缓存污染，SLRU 的多级淘汰制可以减少这种情况的发送。

CountMinSketch 近似计数器器

原理与布隆过滤器类似，将输入的元素通过散列函数映射到不同的数组位置，每个位置每被映射一次该处的计数器就加一。当请求结果时就返回散列结果中计数最小的值作为计数结果，所以会导致类似布隆过滤器“假阳性”的问题，也就是返回计数比实际计数偏大。

W-TinyLFU

LRU 窗口缓存 + CountMinSketch + SLRU 核心流程：

新加入的缓存进入 LRU 窗口缓存
被窗口淘汰的缓存如果 SLRU 段未满则直接进入
否则从 SLRU 尾部选出将被淘汰的缓存 PK 最少使用的会被淘汰，胜利的会进入 SLRU

Reference

title: "W-TinyLFU缓存淘汰策略W-TinyLFU是一种非常优秀的缓存淘汰策略，它综合的考虑了现实场景中可能会遇到的各种问 - 掘金"
image: "https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9cb71ed5731e4cddb4c664381140c6f7~tplv-k3u1fbpfcp-zoom-in-crop-mark:1512:0:0:0.awebp?"
description: "W-TinyLFU是一种非常优秀的缓存淘汰策略，它综合的考虑了现实场景中可能会遇到的各种问题，具有能够提高缓存命中率的准入策略，带有LFU的基于频率的优点，还具备元素保鲜机制，同时还能保证低空间消耗。"
url: "https://juejin.cn/post/7144327955353698334#heading-6"
favicon: ""
aspectRatio: "22.90249433106576"

Spring循环依赖解决

Thu, 27 Nov 2025 09:05:35 +0800

什么是依赖循环？

我们知道在 Spring 中依赖注入时的行为是：

如果当前 Bean 依赖其他 Bean，那么递归注入子 Bean
如果来源于配置文件，则从 Environment 中读取

这就导致了如果 A→B→C→A 成环互相依赖，就会不断递归陷入死循环。就像是死锁一样，互相等待彼此。

类比死锁的解决方案

我们可以借鉴解决死锁的方法来解决依赖循环：

破坏互斥条件：允许所有资源被共享，但这不适用于某些不能共享的资源（如打印机）
破坏不剥夺条件：当进程请求新资源未得到满足时，必须释放所有已占有的资源
破坏请求与保持条件：采用预先静态分配，即进程在运行前一次性申请所有所需资源
破坏循环等待条件：采用顺序资源分配，规定进程必须按照资源的编号顺序来申请

Spring 的选择：

Spring 选择的是破坏循环等待条件（或者说打破了"资源必须完全就绪才能被使用"的互斥条件），允许循环中的 Bean 在未完全初始化结束前，先拿到一个"半成品"引用，从而结束递归等待。

Spring 在哪里、通过什么方法解决了它？

Spring 通过在 Instantiation 之后提前暴露工厂对象，在 Populate 之前，加入到三级缓存，允许其他对象通过 ObjectFactory 获取到 bean。

三级缓存机制

级别	缓存名称	存放内容	作用
一级缓存	singletonObjects	完全初始化好的 Bean	存放成熟的单例 Bean
二级缓存	earlySingletonObjects	半成品的 Bean（提前代理）	解决循环依赖中的 AOP 代理单例问题
三级缓存	singletonFactories	ObjectFactory	延迟决策是否需要代理

具体流程

A 实例化 → 暴露工厂到三级缓存
    ↓
A 填充属性，需要 B
    ↓
B 实例化 → 暴露工厂到三级缓存
    ↓
B 填充属性，需要 A → 从三级缓存获取 A 的工厂 → 创建代理/获取原始对象 → 放入二级缓存
    ↓
B 完成 → 放入一级缓存
    ↓
A 继续填充 B（从一级缓存获取）→ A 完成 → 放入一级缓存

![[../pics/BeanDependencyLoop.png]]

为什么要三级缓存而不是二级？

如果去掉二级缓存会发生什么：

当非 AOP代理的对象注入属性时 B从三级缓存中 getbean获取到A,打破循环，此时B已经已经成熟，放入一级缓存，回到A的属性注入流程，查找一级缓存，发现B存在，完成注入。整体流程没有问题，也就是说在没有AOP代理时是可以的。
当有AOP代理时 B从三级缓存中 getbean获取到proxy012_A，把自身放入一级缓存，A又依赖C，C从三级缓存中获取proxy013_A，回到A，此时B和C拿到的是不同的A的代理对象，违反了单例原则。当加入了二级缓存，获取到proxy_A后会把代理对象放到二级缓存，其他依赖需要时拿到的是同一个代理对象。

为什么不直接在三级缓存中存放代理对象？

Spring 的设计初衷是 AOP 代理应当在 Bean 生命周期最后一步（初始化后）完成。但在 循环依赖 这种极端情况下，为了打破死锁，Spring 此时不得不妥协，允许在 实例化后、填充属性前 提前进行 AOP。

为什么提前暴露“空壳代理”没问题？

因为 Java 是 值传递（传递的是对象引用的地址）。

代理对象（Proxy）内部持有原始对象（Target）的引用。
虽然注入给别人时，原始对象还是“空的”，但随着生命周期继续，原始对象会被填充完好。
当真正调用代理对象方法时，内部委托的原始对象已经是成熟的了。

为什么要三级缓存总结：

三级缓存（ObjectFactory）：它的作用是 “延迟决策”。它存的是一个生成代理的工厂逻辑，而不是具体的对象。只有当循环依赖发生时，才去运行这个逻辑（打破原则）；否则，永远不运行（坚持原则）。Spring选的的是破坏不剥夺条件，允许循环中的Bean先拿到不成熟的Bean，结束递归。
二级缓存（EarlySingletonObjects）：它的作用是 “保持单例”。一旦三级缓存的工厂被执行，生成的代理对象（Proxy）必须放入二级缓存。因为 createProxy 每次都会产生新对象，如果有多个 Bean 依赖它，必须从二级缓存拿同一个 Proxy，保证全局唯一。

为什么构造器注入无法解决依赖循环？

在 Bean 的生命周期中 Instantiation 中如果使用的是构造器注入，会在此步骤直接注入依赖，但暴露工厂对象是在 Instantiation 结束后进行的，此时缓存中没有对象，无法获取到未成熟的Bean 。解决方法：使用懒加载 @Lazy，返回一个空壳，当真正需要该对象时才加载注入属性。

总结

问题	答案
Spring 如何解决循环依赖	三级缓存 + 提前暴露半成品对象
为什么需要三级缓存	三级缓存用于"延迟决策"是否需要代理，二级缓存用于保持代理单例
构造器注入为什么不支持	构造器注入发生在暴露工厂之前
推荐的注入方式	构造器注入（避免循环依赖）+ 必要时使用 @Lazy

Reference

聊透Spring循环依赖 - 掘金

Spring Bean生命周期

Tue, 25 Nov 2025 20:22:35 +0800

Bean 的生命流程简述

Instantitaion
populate
Initialization
使用
结束销毁

Instantiation

什么是 Instatiation？他和 populate 有什么区别？

Spring 的 Bean 创建是控制反转（IoC）的核心体现。容器根据 BeanDefinition 中的元数据（如类名、作用域、构造参数、工厂方法、初始化/销毁方法等），通过 Java 反射机制来实例化 Bean 对象。这个阶段只是‘创建空壳对象’，尚未进行依赖注入。后续 Spring 会基于同样的 BeanDefinition 完成 属性填充（即依赖注入）和初始化，最终将一个完整可用的 Bean 交还给应用。通过这种方式，对象的创建和依赖管理不再由程序员手动控制（比如 new），而是交给了 Spring 容器，实现了控制反转。

三种创建对象的方法

Supplier
工厂方法
构造函数

protected BeanWrapper createBeanInstance(String beanName, RootBeanDefinition mbd, @Nullable Object[] args) {
   //检查获取 BeanDefinition
   Class<?> beanClass = resolveBeanClass(mbd, beanName);

   //首先检查是否提供了 Supplier，如果有就直接返回创建对象
   Supplier<?> instanceSupplier = mbd.getInstanceSupplier();
   if (instanceSupplier != null) {
      return obtainFromSupplier(instanceSupplier, beanName);
   }

   
   //检查是否有工厂方法
   if (mbd.getFactoryMethodName() != null) {
      return instantiateUsingFactoryMethod(beanName, mbd, args);
   }
   
   
   //执行后置处理器, 获取候选构造方法
   Constructor<?>[] ctors = determineConstructorsFromBeanPostProcessors(beanClass, beanName);
   
   if (ctors != null || mbd.getResolvedAutowireMode() == AUTOWIRE_CONSTRUCTOR ||
         mbd.hasConstructorArgumentValues() || !ObjectUtils.isEmpty(args)) {
      return autowireConstructor(beanName, mbd, ctors, args);
   }

   
   return instantiateBean(beanName, mbd);
}

populate

populate 在做什么？

popluate 流程主要是将属性注入到上一步创建好的“空壳对象”，核心是对对象中有 [[@Autowired]] 和 @Resource 的字段 Setter 函数等注入属性，完成这一步后会进行 Initialization 进行 AOP 代理、回调 Aware 接口、回调初始化方法。

属性填充的核心流程

读取 BeanDefinition
Spring 查看这个 Bean 的 PropertyValues（属性值元数据）
解析依赖来源
- 如果依赖来源于其他 Bean，那么递归先去创建该 Bean（如果成环这里就可能诞生 [[依赖循环]]依赖循环的问题）
- 如果来源于配置文件，则从 Environment 中读取
通过反射赋值
- [[Spring/@AutoWired.md|@AutoWired ]]注入（构造器注入已经在 Instantiation 阶段完成）
- @Resource 注入

Initalization

Aware BeanPostProcessor invokeInitMethods() BeanPostFactory.postProcessAfterInitialization()

步骤	名称	作用	代码体现	具体效果
4	`BeanPostProcessor` 前置处理	在初始化方法执行前，允许你对 Bean 做预处理	`postProcessBeforeInitialization`	打印日志，告诉开发者“Bean 即将初始化”，可用于权限检查、日志埋点等。
5	是否实现 `InitializingBean`	Spring 提供的标准初始化回调接口	`afterPropertiesSet()`	在这里做数据校验（如用户名不能为空），确保 Bean 状态合法。
6	是否配置自定义 `init-method`	用户自定义的初始化方法	`myInitMethod()`	在这里做业务初始化（如加载缓存、连接数据库），非常灵活。
7	`BeanPostProcessor` 后置处理	在所有初始化完成后，对 Bean 进行最终处理或包装	`postProcessAfterInitialization`	关键效果：返回一个代理对象！这使得你可以无侵入地给 Bean 添加功能（如事务、日志、安全检查），这就是 AOP 的基础。

! [[../pics/SpringBean.png]]

Destruction

当容器关闭时会调用

DisposableBean.destroy()
destory-method() 与初始化阶段的 InitializingBean.afterPropertiesSet() 和 init_method 对称

总结：Destruction 的核心要点

要点	说明
两个钩子	`DisposableBean.destroy()` + `destroy-method`
执行顺序	`@PreDestroy` → `destroy()` → `destroy-method`
触发条件	必须调用 `context.close()`
为什么重要	防止资源泄漏（数据库连接、线程池、文件句柄等）
最佳实践	用 `@PreDestroy` 注解方法，清晰且解耦

Reference

title: "聊透Spring bean的生命周期一步一图带你理解Spring bean的生命周期，清楚Spring的IOC、DI、A - 掘金"
image: "https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1960950d22104a639e09de10d2bff105~tplv-k3u1fbpfcp-zoom-in-crop-mark:1512:0:0:0.awebp?"
description: "一步一图带你理解Spring bean的生命周期，清楚Spring的IOC、DI、AOP是怎么完成的，并教你如何借助Bean的生命周期，拓展你的应用"
url: "https://juejin.cn/post/7155884227714613285"
favicon: ""
aspectRatio: "24.867724867724867"

title: "聊透Spring依赖注入依赖自动注入；依赖注入模型；[[@AutoWired]]和@Resource依赖注入的解析、超找、注入流 - 掘金"
image: "https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9f2a1a92368a44c8bfb343fc864a7a52~tplv-k3u1fbpfcp-zoom-in-crop-mark:1512:0:0:0.awebp?"
description: "依赖自动注入；依赖注入模型；@AutoWired和@Resource依赖注入的解析、超找、注入流程分析；@Qualifier实现名称查找的原理分析"
url: "https://juejin.cn/post/7143419261657022472"
favicon: ""
aspectRatio: "42.28310502283105"

IoC控制反转与DI依赖注入

Tue, 25 Nov 2025 11:25:35 +0800

什么是 IoC (Inversion of Control) 和 DI (Dependency Injection)？

IoC 控制反转

IoC 控制反转，指的是创建和控制注入 Spring Bean 的操作权反转交给框架去自动完成。

DI 依赖注入

DI 依赖注入，是 IoC 思想在 Spring 的实现，框架自动地将程序所需的依赖注入到 Bean 中。

在 Spring Boot 中的关系

IoC 是设计思想，DI 是实现方式。Spring 容器通过 IoC 容器管理 Bean，并通过 DI 完成依赖注入。

Spring Boot 中如何实现依赖注入？

依赖注入方式有：

注解 @Autowired 直接字段进行注入
Setter() 方法注入
构造函数注入

我们通常会使用 构造函数 和 字段注入。

	字段注入	Setter()注入	构造函数注入
final 不可变对象	❌ 不可注入	❌ 不可注入	✅ 可以
通用性	只适用于 IoC 容器	只适用于 IoC 容器	非 IoC 也适用

解释@Autowired 注解的作用，以及它在 Spring Boot 中的自动装配模式有哪些？

@Autowired 自动装配

什么是 Bean 的作用域 (Scope)？

Spring Boot 支持多种 Bean 作用域：

作用域	描述
singleton	单例模式（默认）
prototype	原型模式，每次请求创建新实例
request	每次 HTTP 请求创建一个实例（Web）
session	同一个 HTTP Session 共享实例
application	ServletContext 生命周期

@Qualifier 和 @Primary 注解

@Qualifier：显式指定 Bean 名称，用于解决多个同类型 Bean 的冲突
@Primary：标记优先使用的 Bean

ApplicationContext 与 BeanFactory

特性	BeanFactory	ApplicationContext
类型	基础接口	BeanFactory 的子接口，更高级
功能	基础的 IoC 容器功能	提供更多企业级特性（事件发布、国际化、资源加载等）
初始化时机	懒加载（getBean 时才初始化）	饿加载（容器启动时预加载所有单例 Bean）
适用场景	资源受限的环境或需要延迟加载	大多数企业应用（推荐使用）

配置文件依赖注入

可以在 application.properties 或 application.yml 中配置属性，然后通过：

@Value("${property.name}") 注入单个属性
@ConfigurationProperties 批量注入属性

依赖反转原则 (DIP)

依赖反转原则（DIP）是 SOLID 原则之一，主张：

高层模块不应依赖低层模块，两者都应依赖抽象
抽象不应依赖细节，细节应依赖抽象

DI 是 DIP 在 Spring 中的具体实现。

pipo's site

Spring 中的 Bind

Bind 是什么？

三种绑定方式

@Value

@ConfigurationProperties

Binder API

读取单个值

读取复杂类型 (List/Map)

读取整个配置类

创建本地 bind 并绑定

三种绑定方式对比

Reference

从 Future 到 CompletableFuture

使用 Future 完成多线程任务 （ThreadPoolExecutor）

快速上手

几个注意点

实战示例

使用现代的 CompletableFuture 完成多线程任务

快速上手

常见的几种方法

创建异步任务

转换结果（链式处理的核心）

消费结果（只关心结果，不返回新值）

异常处理

两个任务组合

多个任务全部完成

实战示例

Reference

Java基础IO

字节流和字符流

读写字符流

读写字节流（二进制）

缓存使用

RandomAccessFile

如何使用

实战示例（多线程复制文件）

Reference

跨域

跨域与 CORS

1) 什么是跨域

2) 请求头是什么

3) CORS 把跨域请求分为两类

A. 简单请求（simple request）

B. 非简单请求（preflighted request）

Reference

Location匹配

匹配类型

优先级

拼接规则

root & index

alias

巨坑

使用精准匹配导致 无法托管正确页面

Reference

Nginx快速入门

安装

导入源（Debian/Ubuntu）

安装 Nginx 软件包

启动与配置

检查语法错误与查看配置所在位置

查看配置

快速配置

反代短链接不跳转：上游依赖 Host 头

背景

现象

关键判断

根因

修复方案

验证方法

Reference

W-TinyLFU

W-TinyLFU

前置理解

SLRU 分段最久未使用

CountMinSketch 近似计数器器

W-TinyLFU

Reference

Spring循环依赖解决

什么是依赖循环？

使用 Future 完成多线程任务（ThreadPoolExecutor）

使用精准匹配导致无法托管正确页面

什么是 Instatiation？他和 populate 有什么区别？