-
静态方法中不能使用this，因为this指向具体对象实例，而静态方法属于类本身、无需实例即可调用，其字节码签名不含this参数，编译期即被禁止。
-
TreeSet不能存null，因其底层依赖compareTo()或Comparator.compare()排序，而null调用这些方法会抛NullPointerException；HashMap允许key为null（仅一个）和任意value为null，ConcurrentHashMap则禁止null作为key或value。
-
Java内存模型中的可见性指线程修改共享变量后其他线程能否及时看到新值，根本原因在于JMM将变量存于主内存而线程操作工作内存副本，且同步无强制时机；volatile通过强制读写主内存解决可见性，但不保证原子性；synchronized等锁机制也通过happens-before规则保障可见性。
-
ByteArrayInputStream是Java中以字节数组为源的轻量级输入流，适用于单元测试、内存解析二进制协议或序列化数据消费；不复制数组、不支持真正重置、非线程安全，慎用于共享或可变数组场景。
-
使用File类可基础遍历目录，通过listFiles()获取子项并判断类型输出；2.推荐使用NIO.2的Files.list()或Files.walk()结合Stream实现高效、安全的目录浏览，支持流式处理与异常管理。
-
JavaPattern/Matcher在处理含Unicode字符（如℃、Ω）的字符串时，若正则表达式未正确覆盖目标字符大小写或编码语义，会导致find()误判成功但group()返回空或null，且start()位置偏移——根本原因常是正则逻辑缺陷，而非Unicode编码问题。
-
removeIf方法通过传入Predicate实现条件删除，如删除偶数或年龄小于18的用户，需注意集合可变性、线程安全及原集合被修改的问题。
-
通过封装、多态和职责分离将业务逻辑与代码结构对齐，用领域对象替代贫血模型，以Order.pay()为例实现内聚校验，利用DiscountStrategy多态消除条件分支，拆分大Service为小聚合如UserRegistration，通过方法名validateEligibilityForPromotion等表达业务意图，使代码具备可读性与扩展性。
-
Java反射是JVM提供的标准能力，通过Class对象动态获取类型信息并调用成员，但存在性能开销与安全限制；获取Class有三种方式，访问成员需区分getDeclaredXXX与getXXX，invoke()调用有三处易错点，且反射影响JIT优化。
-
答案：Java中通过staticfinal声明类常量，final声明局部常量，命名全大写加下划线，提高可读性、便于维护、避免魔法数字，注意必须初始化且引用类型仅地址不可变。
-
Arrays.binarySearch搜不到明明存在的元素是因为它仅对已排序数组有效；未排序或降序数组（未配对应Comparator）会导致结果不可靠，返回负数表示插入点编码而非简单“未找到”。
-
ScheduledThreadPoolExecutor不能替代synchronized，因其仅负责任务调度，不提供线程安全；并发问题需靠任务内部同步机制（如锁、ConcurrentHashMap）解决，而非调度时机。
-
happens-before是什么：不是执行顺序，而是可见性契约它不是说「A一定在B前面CPU执行」，而是向程序员承诺：如果Ahappens-beforeB，那么A对共享变量的修改，对B一定是可见的；且B不能看到A之前某个中间态（比如只写了一半的long值）。这个保证由JVM在编译期插内存屏障、运行时配合CPU指令（如lockxchg或mfence）共同实现。常见误解：把happens-before当作「时间先后」——错。两个操作即使A在
-
IntelliJIDEA在调用第三方库JAR中的接口方法时，常无法显示原始参数名（如name,type），仅显示占位符（如s,i），而默认方法却能正常显示——根本原因在于Java字节码规范对abstract接口方法不强制保留参数名信息，即使编译时加了-parameters也无效。
-
吞吐量优先应选ParallelGC，因其专为最大化吞吐量设计，全程STW但效率高、无协调开销；G1GC仅在兼顾吞吐与软实时停顿（≤200ms）时才适用。
