-
Properties.load()读不到文件主因是路径错误或资源未正确加载，应使用类加载器getResourceAsStream()获取流并判空；中文乱码需用UTF-8Reader加载；SpringBoot中应优先使用@ConfigurationProperties而非手动加载。
-
Arrays.asList()返回固定长度List，不可增删；因其实现类未重写add/remove，调用抛UnsupportedOperationException；基本类型数组会被整体当作单个元素，应改用包装类型或Stream处理。
-
Connection复用的是JDBCConnection对象而非物理TCP连接，节省三次握手等开销；其本质是池化管理带状态的连接实例，需同线程借还，避免跨线程共享、错误关闭或绕过池直连。
-
AudioSystem.getAudioInputStream抛UnsupportedAudioFileException主因是误将麦克风TargetDataLine等原始PCM流当作文件传入，因其无WAV/AIFF等文件头；正确做法是直接调用line.read()读取字节。
-
大多数时候不该在方法里直接try-catchIOException，除非能在当前上下文真正处理（如重试、降级、返回默认值）；否则掩盖问题，导致调用方无法感知失败，引发后续脏数据或空指针等问题。
-
线程池未关闭会导致JVM无法退出和RejectedExecutionException异常；应先调用shutdown()再配合awaitTermination()等待终止，超时后可shutdownNow()；推荐使用AutoCloseable封装或Spring的destroyMethod自动管理。
-
Java应用部署到K8s需先容器化并适配容器生命周期：启用-XX:+UseContainerSupport、合理配置liveness/readiness探针（如/actuator/health/readiness）、避免检查数据库连通性，SpringBoot2.3+推荐用bootBuildImage构建镜像。
-
应优先使用take()而非poll()：take()主动让出CPU、支持中断响应、避免忙循环，而poll()易致CPU飙升且中断处理复杂；ThreadPoolExecutor源码也印证此设计。
-
答案：Maven多模块项目依赖管理核心在于父POM中使用<dependencyManagement>统一版本、合理划分模块实现高内聚低耦合、通过<exclusions>排除冲突传递依赖，并利用mvndependency:tree等工具分析依赖树，结合BOM引入、版本属性化管理等策略，确保依赖一致性与项目可维护性。
-
位运算不直接实现幂次转换，而是支撑快速幂算法：通过b&1判断指数二进制位、b>>=1推进位、a=aa维护幂次、res=resa条件累乘，将时间复杂度降至O(logb)。
-
枚举中声明抽象方法并由各常量用{}块实现，是类型安全、编译强制检查的差异化策略；需配合私有字段复用共性数据，方法签名须稳定，适用于状态机等有限内聚场景。
-
中介者模式不能直接用于分布式路由，因其仅适用于单JVM内对象解耦，缺乏网络传输、节点发现、状态同步等分布式能力；应分层实现：通信层（gRPC/Kafka）、状态管理层（Nacos/Etcd）、路由策略层（面向对象的RoutingMediator接口及其实现）。
-
必须使用GraalVMJDK（22.3+）并手动安装native-image工具，验证java-version含“GraalVM”字样；SpringBoot3项目需启用SpringAOT和native-maven-plugin，显式声明反射、资源等配置，构建时需调大内存与超时参数。
-
类加载过程本身不会直接导致线程死锁，但自定义类加载器设计不当可能因隐式锁竞争、双亲委派缺陷或变量不可见引发“类加载锁死锁”；需从锁行为、类加载路径、变量可见性三方面排查修复。
-
getInterfaces()仅返回直接声明的接口，不递归获取父接口；接口调用时返回其直接extends的父接口；需手动递归+去重才能获得完整继承链；泛型信息丢失，须用getGenericInterfaces()获取。
