本文系统梳理设计模式中单例、代理与适配器/装饰器的核心要点。单例模式分恶汉式（类加载即实例化）与懒汉式（延迟加载+双重检查），前者简单直接但无法延迟，后者确保线程安全但代码复杂，适用全局唯一实例场景。代理模式分静态（预写代理类，代码膨胀风险较高）与动态（ runtime 反射生成，适用于批量日志/权限增强），核心在于控制对象访问。适配器解决接口不兼容问题，本质用包装类统一调用；装饰器叠加功能但不改变类，如Java IO流的压缩/加密装饰。三者目标不同：代理控制访问（延迟/权限），适配器翻译接口，装饰器增强属性。重点要避免模式混淆，每个类仅实现单一意图，重构时应先明确接口再选择模式，而非强行套用名称。常见陷阱包括懒汉式缺失双重检查（导致并发创建实例）、静态代理扩展困难、误用适配器处理依赖关系、装饰器滥用继承等。

Java单元测试框架选型要点：JUnit 5适合纯单模块测试，强调快速反馈（分层注解：@ExtendWith+@Test/こんにちは）和业务行为纯粹性（禁用测实现细节、堆积覆盖率断言）；TestNG长于套件编排（via XML测试ng.xml）和接口自动化（@DataProvider数据驱动），但需注意将重环境初始化放 mata Suite层，避免串行依赖；Mockito用于隔离外部依赖（@Mock/when-thenReturn组合），严格遵循不mock框架固有类型原则，不依赖verifyNoMoreInteractions作为强约束条件。Kotlin项目推荐MockK替代Mockito JVM写法，安卓 instrumentation需搭配DEXMAKER生成类。速查表归纳核心场景选型：纯单元测试首选JUnit5，混合回归需TestNG；外部依赖隔离用Mockito；平台适配关注Mock机制扩展（如MOCKK语法更贴合Kotlin）及环境初始化技术分层（JUnit5 Vintage支持JUnit4迁移）。读者收益：明确技术选型决策树（场景-框架适配）和执行规范（如Skip测类实现细节），避免三大典型误区：过度参数化测试用例、依赖链过深导致的稳定性风险、违规Mock对象引发的false阳性。

Java 代码生成有两种主要方式：编译期使用 APT + JavaPoet + AutoService 生成注解处理代码和 SPI 注册，安全可审计但需避免修改已有源文件；运行期使用 ASM 或 Javassist 修改字节码，可处理动态 Control-Flow nhưng 核 risk higher，改系统类或写错栈帧会崩溃。APT 支持增量编译且错误在编译期暴露，Javassist 生成类需考虑内存缓存（prune）和 Android 对系统类的限制（minify 后类名变化）。核心对比：APT 安全审计强但依赖注解完备性，ASM/Javassist 灵活但易引发运行时错误；前者适合消除路由 DI样板代码，后者用于埋点、热修复等场景。需避免运行期修改系统类，两种方案都存在内存资源管控问题。

Spring生态组件选型与实践需把握核心要点：IOC优先使用构造器注入和三级缓存解决循环依赖，避免getBean滥用；AOP推行面向接口编程需处理自调用和异常回滚规则，注意切面不过度侵入；安全防护建议新项目采用Spring Security（需关闭默认CSRF）并校验密码编码器强度，旧系统维护时注意Shiro的RememberMe密钥防护和权限缓存更新效率；模板引擎Thymeleaf适用于后台管理场景，需防范XSS风险和模板与业务LOGO解耦；云原生选型SCK（K8s原生服务架构）更适合新建云原生项目，SCA（兼容DUBBO/阿里云栈）适用存量改造，混用时需解决双服务发现冲突；AI接入应整合ChatModel与Advisor，严格校验函数调用参数并做单元测试，避免密钥硬编码。各组件选择需对齐业务场景：新项目优先Spring体系，旧系统需评估升级成本和兼容度，云原生项目若已构建IMDS和SPIFFE体系可跳过独立服务注册中心建设。

本文系统梳理Java基础与并发开发要点：1. 哈希码需配合equals使用，注意可变字段对HashMap的影响；2. ArrayList避免作为并发容器，需关注扩容机制与修改导致fail-fast异常；3. Arrays工具类简化数组操作，但需注意asList的固定性及遍历时存在的拆箱陷阱；4. Stream处理需考虑短路机制与并行场景，Android需注意API版本兼容性；5. BigDecimal必须用字符串构造模拟精确小数，避免double精度误差，比较用compareTo而非equals。6. 并发核心机制：通过JMM保证可见有序，AQS与LockSupport实现细粒度控制（park/unpark），要求编写同步器时严格原子化操作。7死锁四大条件需重点防范，可通过资源有序申请或超时机制破坏；8. LRU缓存需配合过期时间与防扫描策略，避免成倍访问激增内存，实际开发应结合LRU-K/LFU均衡淘汰率。9. ThreadLocal若用于线程池必须及时remove，不可替代单例模式或全局参数。附工具速查表强调：同步场景优先用synchronized/volatile，自定义锁基于AQS，严格使用可乐终止器（原子操作），避免滥用多线程直接造线程。核心收获为：遇共享可变状态须多重约束保障一致性，工具链选择要匹配业务特性，设计时尽早考虑高并发与优雅退化。

Java中静态成员属于类而非对象，可通过子类访问。核心要点：静态方法不具备运行时多态，无法被重写，但可通过子类访问父类同名静态方法（方法隐藏）；静态字段同样不能重写，子类同名字段 thuộc字段隐藏。接口静态方法不可被子类继承，调用需使用接口名称。访问权限决定可见性：private成员不可见，protected默认可见，public全类可见。静态成员不参与多态调用，调用时由变量声明类型决定（如 Parent parent = new Child(); parent打印调用的是Parent类的静态方法）。静态方法不能直接访问实例字段，需显式转为对象调用（如user1.printName()）但实际执行避免实例方法的场景。静态调用的编译时绑定特性导致静态成员无法根据实际对象类型动态分发。常见误区包括将方法隐藏误认为重写，静态方法动态绑定等。静态设计仍符合封装、继承等面向对象原则，但属于类级抽象而非对象级实例化。

一、引言：为什么配置文件加密刻不容缓？ 在Spring Boot项目中，数据库密码、API密钥、Redis凭证等敏感信息常常被明文写在application.yml或application.properties中，然后堂而皇之地提交到代码仓库。这无异于把家门钥匙贴在门框上——一旦代码泄露或被内部人员

应用重启时，线程池里的任务怎么办？直接“拔电源”，正在执行的任务会丢失，积压的队列也可能被清空。要做到“优雅关停”，就得在停止服务前，给线程池一个体面的收场：尽力完成进行中的任务、合理地放弃等待，并确保资源回收。 本文将讲解线程池关闭的核心机制，并给出标准化的优雅停机范式。 一、线程池的状态：先看懂

在使用线程池时，你很可能遇到过这种情况：任务明明出错了，日志里却干干净净，就像什么都没发生一样。这其实是因为 线程池默认会“吞掉”某些异常，尤其当你用 submit() 提交 Callable 或 Runnable 时。 本文将彻底梳理线程池异常处理的四种主要方式，并给出最佳实践，帮你告别“异常黑洞

transient 是 Java 中的一个字段修饰符，主要用于对象序列化（Serialization）时控制某些字段不被序列化。 transient 的中文翻译是 "瞬态的" 或 "临时的"。 下面从概念、原理、使用场景、示例和注意事项进行系统讲解。 一、什么是 transient 当一个类实现了