-
jstack-l<pid>是最轻量的死锁检测工具，必须加-l才显示锁关系，推荐配合-e连续执行2–3次；ThreadMXBean可程序化检测已形成的死锁，但无法捕获伪死锁。
-
推荐用DateTimeFormatter而非SimpleDateFormat，它线程安全、不可变、支持ISO与自定义模式，需通过ofPattern、ISO常量或ofLocalizedDateTime等静态工厂创建，不可new；format/parse需类型匹配，时区字符串须用ZonedDateTime/OffsetDateTime解析，应staticfinal复用。
-
死锁的典型现象是Java程序卡住、线程长时间处于BLOCKED或WAITING状态且CPU使用率极低；快速检测方法包括jstack-l查看Found1deadlock、JVM启动加-XX:+PrintConcurrentLocks、JConsole检测死锁；预防手段有tryLock()超时获取、按System.identityHashCode固定顺序加锁、优先使用ConcurrentHashMap等并发工具类替代手动锁。
-
Oracle官网下载JDK需先注册并登录Oracle账号（第三方登录无效），再访问归档页https://www.oracle.com/java/technologies/javase/jdk-archive-downloads.html，选择对应版本与平台，禁用广告拦截插件后勾选许可协议方可下载；\_bin结尾为完整JDK，\_jre为历史残留命名，现代开发应选用\_bin包。
-
异常链是将底层异常包装为高层异常并保留原始异常作为原因，通过带cause参数的构造函数实现，如thrownewBusinessException("业务失败",e)；它既提供业务语义又保留调试信息，打印堆栈时显示“Causedby”，便于排查问题。
-
Arrays专治数组，Collections专治集合；Arrays.sort()不接受List，须用Collections.sort()；Arrays.asList()返回不可变视图，需newArrayList<>包装；同步用Collections.synchronizedList()但复合操作仍需手动同步；基本类型数组排序更快但不稳定，对象排序稳定。
-
var仅限方法体内局部变量声明，需初始化且类型可静态推断，禁用于字段、参数、返回值及lambda形参；推断类型最具体但可能丢失泛型信息，影响可读性与维护性。
-
本文深入解析在使用findViewById()时部分视图（如TextView、RecyclerView）意外返回null的典型场景，重点揭示因UI状态变更、视图可见性控制及初始化顺序不当引发的“伪空指针”问题，并提供可复现的修复方案与最佳实践。
-
Java对象协作核心是职责分离与契约交互：按领域切分对象（如User、InventoryChecker）、用接口+组合实现松耦合、事件机制解耦复杂流程、明确定义方法边界。
-
Java14+的NPE错误行号更准需启用-XX:+ShowCodeDetailsInExceptionMessages，该参数在Java14–17为实验性、Java18+默认启用，但部分JDK如Dragonwell仍需手动开启；编译须保留调试信息（-g），否则提示退化；IDE配置、静态分析（SpotBugs）、Optional合理使用及fail-fast（Objects.requireNonNull）可进一步预防NPE。
-
ResourceBundle.Control是Java资源加载链中唯一可定制“查找、解析、缓存”行为的核心钩子，需在无法热更新properties、需支持YAML/JSON、或需精确控制缓存时自定义；必须重写getCandidateLocales、getFormats、newBundle三个方法，并合理实现缓存与编码处理。
-
本文详解BigDecimal使用double构造器时因浮点数二进制表示缺陷引发的精度丢失问题，揭示为何newBigDecimal(2.55)与newBigDecimal("2.55")语义完全不同，并提供安全、可预测的初始化实践方案。
-
PropertyPermission仅控制System.getProperty的读取权限，不涉及setProperty；启用SecurityManager时会检查该权限，未授权则抛SecurityException；其策略格式为permissionjava.util.PropertyPermission"key","actions";，actions仅支持"read"或"read,write"；虽SecurityManager已弃用，但PropertyPermission仍在沙箱等场景有效；现代方案倾向封
-
nullinstanceof任意类型恒为false，不抛异常；必须先判null再用instanceof，顺序不可反；Java14+可用switch类型模式替代，天然规避null问题。
-
final类本身不直接触发JVM内联，但其方法因不可重写而省去虚方法查表，内联与否取决于方法大小、调用频率和JIT阈值，而非是否final。
