-
使用ConcurrentHashMap可高效实现线程安全的对象注册表，其内置线程安全机制支持高并发读写；若用HashMap则需配合synchronized或ReentrantReadWriteLock，后者适用于读多写少场景，结合单例模式确保全局唯一性，选择方案应基于并发模式与性能需求。
-
Random多线程下变慢因seed竞争导致CAS自旋耗CPU；ThreadLocalRandom必须每次调用current()，不可static缓存；高频场景应提取为局部变量；推荐用nextInt(origin,bound)明确范围。
-
当使用ArrayList存储对象时，若getProduct(intindex)方法中错误地将索引边界判断写为index>0，会导致索引0被拒绝访问而返回null，这是典型的零索引误判问题。
-
Java运行jar包时，命令行参数必须放在-jar选项和jar文件路径之后；JVM参数如-Xmx、-D需置于-jar之前；错误地将应用参数放-jar前会导致“找不到主类”错误。
-
Java递归抛出StackOverflowError是因为线程栈空间耗尽：每层递归压入栈帧，超过JVM默认栈容量（如1MB）即崩溃，与逻辑正确性无关，常见于树遍历、嵌套JSON解析等场景。
-
偏向锁被禁用的直接原因是对象头中hashcode占用了markword的锁状态位，导致偏向锁信息无法写入，二者在31/62位空间内互斥。
-
DelayQueue入队推荐使用offer(Ee)，它要求元素实现Delayed接口（通常还实现Comparable），成功返回true，null抛NullPointerException；put(Ee)和add(Ee)虽存在但不推荐，因无界队列中put等价offer，add则异常处理冗余。
-
Condition是Java中用于线程协作的接口，需与Lock配合使用，支持多条件等待和精确唤醒；示例中通过notFull和notEmpty两个Condition实现生产者-消费者模型，相比synchronized+wait/notify，具备可中断、超时等待及更灵活的锁控制优势。
-
双亲委派被打破是常态，JDBC、Tomcat、OSGi、SpringBoot均主动打破以解决类隔离或热加载需求；重写loadClass()需优先委派系统类，再加载自定义类，否则易触发NoClassDefFoundError。
-
非公平锁的lock()能“插队”是因为在方法开头直接CAS抢占，成功即获锁；仅在锁空闲时有效，否则退化为排队逻辑。
-
LinkedHashMap通过双向链表维护插入顺序，遍历时按插入顺序返回元素，适用于缓存、日志等场景；1.可用默认构造、指定容量、负载因子或从其他Map初始化；2.使用put插入、get访问，遍历顺序与插入一致；3.设置accessOrder为true可启用访问顺序，最近访问元素移至末尾，适合LRU缓存；4.重写removeEldestEntry方法并启用访问顺序可实现LRU缓存，如returnsize()>3;综上，LinkedHashMap在保持顺序的同时性能接近HashMap，是有序场景的理想
-
高层模块和低层模块都应依赖抽象，抽象不应依赖细节。通过接口隔离变化，如UserService依赖UserRepository接口而非具体实现，实现解耦；结合Spring依赖注入可动态切换实现；提升可测试性，便于Mock；支持并行开发，促进团队协作；核心在于识别变化点，提前抽象，增强系统灵活性与可维护性。
-
断言默认关闭，需用-ea启用，语法为assert布尔表达式或assert布尔表达式:错误信息，用于调试时验证条件。
-
DecimalFormat格式化结果为String，不可直接用于数学运算；需参与计算时应优先使用BigDecimal配合setScale和HALF_UP模式确保精度与四舍五入可控。
-
Java项目配置GradleWrapper的核心是自带可执行Gradle分发包以保证构建一致性，通过gradlewrapper命令生成脚本及配置文件，所有构建须用./gradlew触发，并确保相关文件纳入版本控制。
