-
Java反射调用私有方法抛IllegalAccessException，主因是Java9+模块系统强化封装，需setAccessible(true)且配合--add-opens等JVM参数才能跨模块访问。
-
InetAddress.getLocalHost()返回127.0.0.1是因优先查hosts文件而非网卡，正确方式是遍历NetworkInterface过滤非回环IPv4地址，或外部显式配置IP。
-
根本原因是泛型擦除导致类型信息丢失且实际元素不满足Comparable合约；例如List<Object>混存Integer和String时编译通过但运行抛ClassCastException。
-
Java数组需先声明类型再指定长度，推荐int[]arr;形式；声明后为null，须用newint[5]或{1,2,3}显式初始化；不可运行时改长，字面量仅限声明时使用；遍历依需求选for（需索引/修改）或for-each（仅读取）。
-
Future是Java中用于获取异步任务结果的核心接口，通过ExecutorService提交Callable任务并调用get()方法获取结果，支持超时控制、状态轮询和批量任务处理，但易阻塞，复杂场景推荐使用CompletableFuture。
-
适合用switch的典型场景是根据离散、有限、编译期可确定的值（如枚举、整数常量、字符串字面量、密封类）做分支跳转；不适用范围判断、null值、动态字符串或需复杂逻辑的场景。
-
Files.copy()抛NoSuchFileException时需先用Files.createDirectories()创建目标父目录，并显式传入StandardCopyOption.REPLACE_EXISTING才能覆盖；避免字符串拼接路径，应使用Paths.get()。
-
parallel()并非调用即并行，实际执行取决于ForkJoinPool.commonPool()线程可用性及数据源是否支持高效分割（如ArrayList可、LinkedList不可）；常见错误包括共享变量非原子操作、forEach无序不安全、未预热导致性能误判，优化关键在确认其真比串行快且无竞态。
-
本文详解Java泛型中在静态变量声明中合法使用List<?extendsShape>等通配符类型的原因，澄清“通配符不能用于静态上下文”的常见误解，并说明为何history.add(shapes)不违反PECS原则。
-
Class对象是反射的唯一入口；它由JVM类加载后生成，是获取Constructor、Method、Field的起点，forName会初始化类而User.class不会，三者返回同一Class实例。
-
Log4j2异步日志未生效是因为未显式启用异步机制：必须同时引入log4j-core与Disruptor（≥3.4.4）依赖，并添加JVM参数-Dlog4j2.contextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector，否则AsyncLogger退化为同步。
-
JRebel热更失效主因是rebel.xml未生成或IDE未传-javaagent参数；需验证文件存在、关闭SpringBootDevTools、配置jrebel.spring-mvc=true，并注意静态字段、字节码增强及远程部署权限问题。
-
ArrayDeque为什么比Stack快因为Stack是基于Vector实现的，所有操作都带同步开销（synchronized），哪怕你根本不需要线程安全；而ArrayDeque是无锁、数组驱动、双端动态扩容的结构，push/pop/peek全是O(1)均摊，没有冗余边界检查或装箱。常见错误现象：Stack在高并发或高频调用时CPU火焰图里能看到明显java.util.Vector.synchronized占比；换成ArrayDeque后GC次数下降，尤其在短
-
垃圾回收是JVM自动管理内存的核心机制，通过识别并清除堆中不再被引用的对象来释放内存。Java采用可达性分析算法判断对象是否可回收，以GCRoots为起点，未被引用链关联的对象被视为垃圾。常见的回收器包括Serial、Parallel、CMS（已弃用）、G1、ZGC和Shenandoah，适用于不同场景。堆内存分为年轻代和老年代，新对象先分配在Eden区，经历多次MinorGC后存活的对象晋升至老年代，老年代触发的FullGC较慢，应尽量减少其频率。合理编码与JVM调优可提升性能。
-
应先诊断内存问题根源而非盲目调大-Xmx：用jstat查老年代增长、jmap分析对象分布，确认是否泄漏或突发加载；自动堆转储优于手动；G1非万能，需结合GC日志调优；GC日志须独立配置并轮转。
