-
SQLException是checkedexception，因数据库操作天然不可靠，JDBC规范强制处理以避免静默失败；它不自动触发回滚，需显式调用rollback()或配置Spring的rollbackFor。
-
Math.random()生成[0,1)的double，获取1~6随机整数应写为(int)(Math.random()*6)+1；Math.abs(Integer.MIN_VALUE)仍返回负值，可用Math.absExact()避免；2的n次方优先用1L<<n而非Math.pow(2,n)。
-
安全捕获异常关键变量需在异常发生现场提取：优先用自定义异常构造参数传入业务ID；避免反射、toString()等高危操作；集合只记size和前3元素；时间转ISO格式；MDC存简单类型上下文并及时清理。
-
peek是Stream的中间操作，用于调试时查看中间元素而不改变数据流。与map不同，peek不转换元素；与forEach不同，forEach是终止操作。常见误区是忽略Stream惰性求值，缺少终止操作时peek不会执行。使用peek可打印每步流转的元素，如过滤、映射前后的值，帮助定位问题。处理对象时可通过自定义输出关键字段提升可读性。注意事项：仅用于调试，避免修改状态，确保有终止操作，不依赖并行流中顺序。推荐结合日志框架使用，合理利用peek能显著提升Stream链式调用的可观察性与调试效率。
-
CMS、G1、ZGC性能演进聚焦停顿可控性、大堆适应性、碎片治理：CMS“尽量少停”但碎片致FullGC不可控；G1实现“可设上限”停顿；ZGC迈向“几乎不停”。
-
公平锁按线程等待时间顺序分配锁，非公平锁允许插队；2.公平锁通过newReentrantLock(true)创建，保证FIFO，避免饥饿但性能较低；3.非公平锁为默认方式，直接尝试CAS获取锁，吞吐量高但可能引发线程饥饿；4.synchronized是非公平锁；5.非公平锁因高效成为默认推荐，选择取决于公平性与性能权衡。
-
不能只用instanceof判断类型，因其破坏equals对称性；应使用getClass()确保同一具体类；ID为null时须用Objects.equals安全比较；忽略其他字段需严格依据业务契约；equals与hashCode必须一致且仅基于id。
-
ArrayBlockingQueue是线程安全的有界阻塞队列，基于数组实现，使用ReentrantLock保证同步，创建时需指定容量且不可变，支持公平与非公平策略；提供add、offer、put等入队方法，其中put在队列满时阻塞，适合生产者；提供poll、take、peek等出队方法，其中take在队列空时阻塞，适合消费者；常用于生产者-消费者模型，如任务调度与线程池，需注意合理设置容量与处理中断异常。
-
accessOrder必须显式设为true才启用访问顺序，使get()或put()已存在key时将对应Entry移至链表尾部；默认false按插入顺序维护，LRU失效。
-
静态代码块在类加载时执行且仅一次，构造块在new对象时、super()后执行；继承中父类静态块先于子类执行，构造块按父→子顺序插入各构造方法开头。
-
本文讲解如何在Java中通过if-else或算术运算，将个体鸡蛋数量（如15个）智能拆分为“整打数+剩余单个数”，并基于不同单价（整打$1.00、单个$0.10）实现无误差总价计算。
-
ThreadDeath是JVM内部用于已废弃的Thread.stop()的错误信号，继承自Error，无法被真正捕获或处理；现代Java应使用协作式中断机制替代。
-
结论：热点探测的价值体现在混合模式下JVM动态选择编译时机，而非纯解释或纯编译的极端对比；-Xint和-Xcomp绕过真实机制，无法体现CompileThreshold等参数作用；需通过-XX:+PrintCompilation等观察实际热点方法识别与优化行为。
-
优化Java数据结构需从业务建模出发，避免贫血模型，采用DDD思想封装数据与行为，合理使用值对象；根据读写特性选择集合类型，优先使用HashMap/TreeSet提升查询效率，对外暴露不可变视图；减少GC压力，通过对象池、懒加载及StringBuilder优化对象创建；优先组合而非继承，利用接口与策略模式解耦，保持系统灵活可扩展。
-
LambdaConversionException是JVM运行时Lambda转换失败抛出的RuntimeException，表明方法签名不匹配、目标不可见或字节码元信息损坏，非业务异常，需检查MethodType、可见性及构建工具链。
