2026年5月28日笔记
get put post请求流只能请求一次，不能进行再次请求，内部原理是啥？
核心原因是请求体以流的形式存在，具有 “一次性消费” 的特性，且 HTTP 协议和 Web 框架的设计都遵循这一原则，以优化性能并避免潜在的逻辑问题。如果需要重复使用请求数据，通常需要在第一次读取时将其缓存（如存入变量或对象）。
如何避免在GET请求中发送敏感信息？
避免用 GET 传输敏感信息，优先使用 POST 等方法并配合 HTTPS。若必须使用 GET，则需结合加密和临时令牌机制，同时严格限制敏感数据的暴露范围和生命周期。
Synchronized和Lock有什么区别？
| 特性 | synchronized | Lock |
|---|---|---|
| 实现方式 | JVM 内置关键字 | 接口（java.util.concurrent.locks） |
| 锁释放 | 自动释放 | 手动释放（需unlock()） |
| 可中断性 | 不可中断 | 支持中断（lockInterruptibly()） |
| 超时获取 | 不支持 | 支持（tryLock(time)） |
| 公平锁 | 不支持 | 支持（构造函数指定） |
| 条件变量 | 仅一个（依赖Object方法） | 多个（Condition） |
| 灵活性 | 低（固定语法） | 高（可自定义逻辑） |
使用建议：
- 简单同步场景优先用
synchronized（简洁、不易出错）。 - 复杂场景（如超时、中断、多条件通信）用
Lock（更灵活）