1. 面试题的价值为什么“基础”才是真正的分水岭又到了一年一度的招聘季或者说是程序员们“查漏补缺”的季节。每当看到“Java基础面试题”这样的标题很多工作三五年的朋友可能会下意识地划走觉得这些都是“小儿科”自己早已在微服务、高并发、分布式事务的海洋里遨游谁还关心那些老掉牙的String、集合和线程基础但根据我这些年面试过上百位Java工程师的经验来看恰恰是这些最基础的题目成了区分“熟练工”和“明白人”最有效的标尺。一个候选人能滔滔不绝地讲清楚Spring Cloud的组件和CAP理论这很好但这可能只是“会用框架”。而当他被问到“HashMap在JDK1.8中链表转红黑树的具体阈值是多少为什么是这个数”或者“String s new String(abc)创建了几个对象分别在内存的什么区域”时他的回答才能真正反映出对Java语言本身、对JVM内存模型的理解深度。这种深度直接决定了他未来在面对复杂系统BUG、进行性能调优、设计稳健架构时的天花板。基础不牢地动山摇。框架和工具日新月异但Java语言的核心机制和设计思想其变化是相对缓慢而深刻的。掌握这些才是你技术生涯里最保值的资产。所以这份2023年最新的Java基础面试题梳理目的不是罗列一堆问题和标准答案让你去背。而是希望通过拆解每一个高频考点背后的“为什么”帮你重新构建起对Java基础的体系化认知。无论你是即将踏入职场的新人还是希望夯实根基、寻求突破的中高级开发者相信都能从中获得新的启发。我们不会停留在“HashMap线程不安全”这样的结论上我们会深入它的数据结构演进、并发场景下的死链问题、以及CurrentHashMap如何精巧地解决它。准备好了吗让我们从最核心的JVM和内存模型开始。2. JVM与内存管理从对象诞生到GC回收的全链路透视几乎所有Java面试的开场或核心都绕不开JVM。面试官通过它能快速评估你对程序运行环境的理解层次。这里的关键不是死记硬背几个内存区域的名字而是理解数据在整个生命周期中的流转轨迹。2.1 对象的一生堆、栈、方法区与直接内存的协奏曲当你在代码中写下Object obj new Object()这行简单的语句时一场精密的协作就在JVM中展开了。首先new Object()这个指令会在堆Heap中开辟一块内存空间用于存储这个Object实例对象的所有数据虽然这个Object对象内部是空的但对象头等元数据依然存在。堆是所有线程共享的区域也是GC垃圾回收主要发生的战场。接着Object obj这个引用变量本身它的存储位置取决于它的作用域。如果它是一个局部变量在方法内部声明那么它会被存放在虚拟机栈Java Virtual Machine Stack的栈帧的局部变量表中。每个线程都有自己独立的虚拟机栈栈帧随着方法的调用而创建随着方法结束而销毁。这里的obj存放的是那个堆中对象内存地址的引用可以理解为指针或地址。如果obj是一个类的成员变量实例变量那么它将会作为对象的一部分直接存储在堆内存中该对象实例的内部。那么new Object()这个指令本身以及它对应的类信息Object.class从哪里来呢这些信息类的结构、方法代码、常量池等存储在方法区Method Area在JDK 8及之后它的实现叫做元空间Metaspace使用的是本地内存。类加载器会将Object.class文件加载进来解析后形成类元数据存放在这里。还有一个容易被忽视但越来越重要的区域——直接内存Direct Memory或者叫堆外内存。它不是JVM运行时数据区的一部分但通过NIO中的DirectByteBuffer可以直接分配和访问。它的分配和回收不受Java堆大小的限制但受本机总内存的限制其回收依赖于DirectByteBuffer对象本身的GC以及底层sun.misc.Cleaner的清理机制。在涉及大量I/O操作如网络传输、文件读写时使用直接内存可以减少一次从堆内拷贝到堆外系统内存的开销能显著提升性能。所以回答“创建了几个对象”的问题时思路要清晰String s new String(abc)。如果字符串常量池中原来没有abc那么会先在堆中的字符串常量池注意JDK 7以后常量池已移至堆中创建一个abc字符串对象。new String()会在堆中非常量池区域再创建一个新的String对象。局部变量引用s存储在虚拟机栈中指向堆中那个new出来的对象。 因此通常说创建了2个对象一个在常量池一个在堆中普通区域但要注意常量池的对象是复用机制如果之前已存在则这一步不会新建。2.2 垃圾回收机制分代收集理论与GC算法的实战选择理解了对象在哪就要理解对象如何被清理。JVM的GC不是蛮干而是基于一个观察到的现象绝大多数对象都是“朝生夕死”的。这就是著名的“弱分代假说”。基于此HotSpot JVM将堆内存进行了逻辑上的分代新生代Young Generation新创建的对象优先分配在这里。新生代又分为一个Eden区和两个Survivor区S0, S1。对象首先在Eden区分配当Eden区满时会触发一次Minor GC。存活的对象会被移动到其中一个Survivor区比如S0。下次Eden区再满时会对Eden和S0区一起进行GC存活的对象年龄加1并被移动到S1区。如此反复在S0和S1之间复制。默认年龄达到15可调的对象会被晋升到老年代。老年代Old Generation在新生代中经历了多次GC依然存活的对象即“长寿”对象会被晋升到这里。老年代区域较大GC频率远低于新生代。当老年代空间不足时会触发Major GC或Full GC后者通常会对整个堆包括新生代、老年代有时还有方法区进行回收停顿时间STW较长。永久代/元空间存放类元数据在Full GC时也会被清理。不同的区域基于其对象存活特性采用了不同的GC算法复制算法用于新生代。将内存分为两块每次只使用一块当这块用完了就将还存活的对象复制到另一块上然后一次性清理掉已使用的内存。简单高效没有碎片但代价是可用内存折半。HotSpot的Survivor区设计优化了这一点因为通常只有少量对象存活。标记-清除算法用于老年代。分为“标记”和“清除”两个阶段。标记所有需要回收的对象然后统一回收。缺点是会产生内存碎片。标记-整理算法也用于老年代。标记过程与“标记-清除”一样但后续不是直接清除而是让所有存活的对象都向一端移动然后直接清理掉边界以外的内存。解决了碎片问题但移动对象成本较高。现代的GC器如G1、ZGC、Shenandoah已经超越了简单的分代模型采用了更复杂的区域划分和回收策略但理解经典分代模型是理解所有高级GC器的基础。面试中常问的“GC Roots有哪些”就是标记阶段的起点包括虚拟机栈中引用的对象、方法区中静态属性引用的对象、方法区中常量引用的对象、本地方法栈中JNI引用的对象等。实操心得很多线上Full GC频繁的故障根源不在于GC算法本身而在于代码层面。比如不当的静态集合使用导致生命周期过长的对象积累内存泄漏或者大量大对象直接分配在老年代比如未使用池化技术的数据库连接、大的JSON/XML字符串都会导致老年代过快被填满触发Full GC。排查时结合MAT或JProfiler等工具分析堆转储找到这些“长寿”或“巨无霸”对象的引用链是解决问题的关键。3. 集合框架深度剖析数据结构、并发安全与性能取舍集合是Java中使用最频繁的API之一但“会用”和“懂其所以然”是天壤之别。面试官在这里埋的坑往往集中在数据结构、扩容机制和线程安全上。3.1 HashMap的演进从链表散列到红黑树优化HashMap是面试的永恒焦点。它的核心是一个“数组链表/红黑树”的结构。当你调用put(key, value)时计算key的哈希值hashCode()再通过扰动函数高16位与低16位异或目的是增加低位的随机性减少碰撞得到最终的hash值。通过(n - 1) hash计算数组下标n是数组长度为2的幂这样操作等价于取模但效率更高。如果该位置为空直接插入Node节点。如果不为空哈希碰撞则遍历该位置的链表或树。用equals()方法比较key。如果找到相同key则覆盖value否则将新节点插入链表末尾或树中。在JDK 1.8之前发生哈希碰撞时只会形成链表。在极端情况下比如所有key的哈希值都映射到同一个桶HashMap会退化为一个链表查询时间复杂度从O(1)恶化到O(n)。JDK 1.8引入了红黑树进行优化当单个桶中的链表长度超过8TREEIFY_THRESHOLD并且当前数组长度大于等于64MIN_TREEIFY_CAPACITY时该链表会转换为红黑树。这样在最坏情况下的查询时间复杂度可以提升到O(log n)。为什么阈值是8这是基于泊松分布的概率统计在理想的随机哈希下链表长度达到8的概率极低小于千万分之一是一种空间与时间的权衡。扩容机制是另一个重点。HashMap有一个负载因子loadFactor默认0.75和容量capacity。当size capacity * loadFactor时会发生扩容resize即创建一个新的数组通常是原长度的2倍然后将所有元素重新计算哈希并分配到新数组中。这是一个相对耗时的操作。所以如果你能预估大致的数据量最好在创建HashMap时指定一个初始容量避免多次扩容。例如预计要存放1000个元素可以设置new HashMap(2048)因为 2048 * 0.75 1000。避坑指南HashMap的线程不安全体现在哪里主要是在多线程并发扩容时可能形成循环链表导致后续的get()操作陷入死循环JDK 1.7及之前。JDK 1.8通过优化扩容时链表的迁移顺序保持原有顺序解决了死循环问题但并没有解决数据覆盖等并发修改的问题。因此多线程环境必须使用ConcurrentHashMap或Collections.synchronizedMap()。3.2 ConcurrentHashMap的并发之道从分段锁到CASsynchronized既然HashMap线程不安全那么它的并发版本ConcurrentHashMapCHM是如何实现的它的设计哲学经历了从粗粒度锁到细粒度锁再到乐观锁的演进。在JDK 1.7中CHM采用了分段锁Segment机制。它将整个数据分成一个个小的Segment继承自ReentrantLock每个Segment管理一个小的哈希表。put操作只需要锁住对应的Segment其他Segment仍然可以并发访问。这降低了锁的粒度提升了并发度。在JDK 1.8中CHM进行了彻底的重构设计更加精巧。它摒弃了Segment采用了Node数组 链表/红黑树的结构与HashMap类似。其并发控制主要通过以下方式实现CASCompare-And-Swap用于初始化数组、向空桶中插入节点等无竞争场景。这是一种乐观锁在硬件层面保证原子性性能远高于互斥锁。synchronized当发生哈希碰撞需要操作链表或红黑树时则对链表的头节点或树的根节点使用synchronized关键字进行加锁。由于锁的粒度非常细只锁住一个桶并发冲突的概率大大降低性能极高。这种“CAS synchronized”的组合结合volatile修饰的Node节点保证可见性使得JDK 1.8的CHM在保证线程安全的同时获得了接近HashMap的性能。它的size()方法也不再像JDK 1.7那样需要全局加锁而是通过一个CounterCell数组一种分片计数思想来累加最后求和是一个弱一致性的结果。集合选型速查表场景需求推荐实现类关键理由与注意事项单线程需要键值对关注性能HashMap性能最优无序。注意指定初始容量避免扩容。多线程并发高吞吐量键值对ConcurrentHashMapJDK 1.8性能极佳分段锁思想已过时首选此方案。需要按插入顺序或访问顺序迭代LinkedHashMap在HashMap基础上维护了双向链表可实现LRU缓存。需要键值对且线程安全并发度不高Hashtable或Collections.synchronizedMap(new HashMap())全表锁性能较差是遗留类不推荐在新代码中使用。只需要去重的元素集合HashSet(基于HashMap)内部使用HashMap实现元素作为KeyValue是一个固定的Object。需要有序且不重复的集合TreeSet(基于TreeMap)基于红黑树元素必须实现Comparable或传入Comparator。需要线程安全的列表写少读多CopyOnWriteArrayList写时复制读操作完全无锁适合监听器列表等场景。需要线程安全的列表高并发写Collections.synchronizedList(new ArrayList())内部使用互斥锁写多时可能成为瓶颈考虑用ConcurrentLinkedQueue。4. 多线程与并发编程核心机制与避坑实践并发是Java面试中最能体现功力的模块之一。它不仅仅是API的使用更是对计算机底层原理、JMMJava内存模型的深刻理解。4.1 线程状态与协作wait、notify、sleep与join的辨析Java线程在其生命周期中并非只有“运行”和“非运行”两种状态。理解其精确的状态机转换是调试复杂并发程序的基础。NEW新建线程被创建但尚未调用start()。RUNNABLE可运行调用start()后线程处于此状态。它可能在等待CPU时间片也可能正在执行。BLOCKED阻塞线程在等待获取一个监视器锁synchronized时进入此状态。比如线程A持有锁线程B尝试进入synchronized块则B进入BLOCKED状态。WAITING等待线程进入此状态需要等待其他线程显式地唤醒。触发方式调用Object.wait()不指定超时、Thread.join()不指定超时、LockSupport.park()。TIMED_WAITING超时等待与WAITING类似但设置了超时时间。触发方式Thread.sleep(long)、Object.wait(long)、Thread.join(long)、LockSupport.parkNanos()等。TERMINATED终止线程执行完毕。这里重点区分几个易混方法Thread.sleep(long millis)静态方法使当前线程暂停执行指定的毫秒数不会释放任何持有的锁。主要用于暂停执行与锁无关。Object.wait()/Object.wait(long timeout)实例方法必须在synchronized块内调用。调用后当前线程会释放该对象的锁并进入WAITING/TIMED_WAITING状态等待其他线程调用同一对象的notify()/notifyAll()来唤醒。它是线程间协作的基础。Object.notify()/notifyAll()唤醒在此对象监视器上等待的单个/所有线程。被唤醒的线程需要重新竞争对象的锁。Thread.join()等待目标线程终止。底层是通过wait()机制实现的。比如在主线程中调用threadA.join()主线程会等待threadA执行完毕。常见误区很多人认为sleep()会释放锁这是错误的。一个持有锁的线程调用sleep()其他需要同一把锁的线程依然会阻塞。而wait()会释放锁这正是它能用于线程间协作的原因。4.2 volatile与synchronized可见性、有序性与原子性的守卫者这是并发基础中最核心的两个关键字它们解决了不同层面的问题。volatile关键字解决的是可见性和有序性问题。可见性当一个变量被声明为volatile后任何线程对该变量的写操作都会立即刷新到主内存并且会强制使其他线程中该变量的缓存行失效从而其他线程在读取时必须从主内存重新加载。这保证了多线程环境下一个线程对变量的修改对其他线程是立即可见的。有序性禁止指令重排序。普通的变量仅保证在单线程内执行结果的正确性as-if-serial语义但编译器和处理器可能会对指令进行重排序优化。volatile通过插入内存屏障Memory Barrier来禁止这种重排序保证了volatile变量读写操作的前后顺序。局限性volatile不保证原子性。经典的例子是volatile int i 0; i;。i操作实际上分为读、改、写三步volatile只能保证每次读是最新值但多个线程可能同时读到同一个值然后各自加1写回导致最终结果小于预期。synchronized关键字则是一个重量级的解决方案它同时保证了原子性、可见性和有序性。原子性通过互斥锁确保同一时刻只有一个线程能执行同步代码块或方法。可见性在释放锁之前会将工作内存中的共享变量刷新到主内存在获取锁之后会清空工作内存中共享变量的值从主内存重新加载。有序性同步代码块内的指令虽然可能被重排序但由于“管程锁定规则”一个解锁操作先行发生于后续对同一个锁的加锁操作这间接保证了有序性。选择策略如果只是需要一个共享的标志位如boolean flag且对其的操作为简单的赋值flag true使用volatile是轻量且正确的。如果需要保证一组操作的原子性如i 或者check-then-act操作必须使用synchronized或java.util.concurrent.atomic包下的原子类如AtomicInteger其内部使用了CAS操作。4.3 ThreadLocal原理与内存泄漏防范ThreadLocal提供了线程局部变量每个线程都有自己独立的变量副本避免了共享变量带来的线程安全问题。它的典型应用场景是数据库连接、Session管理等需要线程隔离的场景。其原理是每个Thread对象内部都有一个ThreadLocal.ThreadLocalMap类型的变量threadLocals。这个Map的Key是ThreadLocal实例本身弱引用Value是存储的值。当调用ThreadLocal.set(value)时实际上是以当前ThreadLocal实例为Key将value存入当前线程的threadLocals这个Map中。内存泄漏风险是ThreadLocal面试必问点。风险来源于ThreadLocalMap的Entry设计KeyThreadLocal实例是弱引用而Value是强引用。当ThreadLocal实例没有外部强引用时比如被置为null在GC时由于Key是弱引用会被回收此时Entry就变成了null - value。这个Value仍然被Entry强引用而Entry又被ThreadLocalMap强引用ThreadLocalMap又被Thread强引用。只要线程不终止例如使用线程池的核心线程这个Value对象就永远无法被回收造成内存泄漏。如何避免及时调用remove()在使用完ThreadLocal变量后务必调用其remove()方法将当前线程的ThreadLocalMap中对应的Entry删除。这是最根本的解决方法。使用try-finally块将remove()放在finally块中确保执行。使用private static final修饰将ThreadLocal声明为静态常量使其生命周期与类一致避免因ThreadLocal实例被回收而Key为null的情况。但这并不能解决Value的泄漏仍需remove()。实战经验在线程池场景下ThreadLocal的内存泄漏问题会被放大。因为池中的线程会复用生命周期很长。如果上一个任务设置了ThreadLocal变量但没有清理那么下一个任务可能会读到错误的数据脏数据并且原来的Value会一直泄漏。因此在基于线程池的Web服务器如Tomcat或任何异步框架中使用ThreadLocal时清理工作至关重要。5. IO与NIO从阻塞到非阻塞的性能跃迁之路Java的IO体系庞大但面试焦点通常集中在传统BIO与NIO/AIO的对比以及NIO的核心组件上。理解这一块对于构建高性能网络应用至关重要。5.1 BIO、NIO与AIO模型演进与适用场景BIOBlocking IO同步阻塞IO这是JDK 1.4之前的经典模型。服务器为每个客户端连接创建一个独立的线程进行处理。ServerSocket.accept()和Socket.getInputStream().read()都是阻塞方法。当连接数暴涨时线程数也随之暴涨线程的创建、销毁和上下文切换会消耗大量系统资源导致性能急剧下降。它的编程模型简单直观但仅适用于连接数不多且稳定的场景。NIONew IO / Non-blocking IO同步非阻塞IOJDK 1.4引入核心是通道Channel、缓冲区Buffer和选择器Selector。非阻塞通过配置SocketChannel的read/write和ServerSocketChannel的accept操作可以立即返回而不必一直等待数据就绪。这使得一个线程可以管理多个通道。选择器一个线程使用一个Selector可以轮询注册在其上的多个Channel。当某个Channel上有事件如连接就绪、读就绪、写就绪发生时Selector会通知程序程序再处理这些就绪的事件。这就是I/O多路复用模型。缓冲区所有数据都通过Buffer对象来读写提供了对数据的结构化访问。NIO模型用一个或少量线程处理大量连接极大地提升了服务器的并发能力。Netty、Tomcat NIO Connector等高性能框架都基于此模型。AIOAsynchronous IO异步非阻塞IOJDK 1.7引入也称为NIO.2。它提供了真正的异步能力。应用程序发起一个IO操作如read后立即返回操作系统内核完成整个操作数据从内核空间拷贝到用户空间后会主动回调应用程序指定的回调函数。AIO理论上性能更高但实现复杂且在Linux系统上底层实现仍基于epoll并非真正的异步因此在实际生产中使用不如NIO广泛。模型对比表特性BIONIOAIO通信模型同步阻塞同步非阻塞多路复用异步非阻塞编程复杂度简单复杂非常复杂可靠性高高高吞吐量低高理论上最高适用场景连接数少且固定1000高并发、长连接如IM、RPC高并发、连接数多且操作耗时如文件IO5.2 NIO核心组件详解Selector、Channel与Buffer的协作要理解NIO必须吃透这三个核心类的关系。Buffer缓冲区本质上是一个可以读写数据的内存块。有三个关键属性容量Capacity缓冲区最大数据容量创建后不可变。位置Position下一个要读取或写入的数据的索引。界限Limit第一个不应该读取或写入的数据的索引。 操作Buffer有一套固定的模式flip()写模式切换为读模式、clear()清空缓冲区准备写入、compact()压缩未读数据准备继续写入。Channel通道类似于流但可以同时进行读写且数据必须通过Buffer来传递。主要的Channel有FileChannel、DatagramChannelUDP、SocketChannel、ServerSocketChannel。Selector选择器NIO的灵魂。一个Selector可以注册多个Channel并监听这些Channel上的事件SelectionKey.OP_ACCEPT,OP_CONNECT,OP_READ,OP_WRITE。通过调用Selector.select()方法它会阻塞直到有注册的事件发生然后返回一个SelectionKey集合程序遍历这个集合来处理就绪的Channel。一个典型的NIO服务器代码骨架如下// 1. 创建Selector Selector selector Selector.open(); // 2. 创建ServerSocketChannel并设置为非阻塞 ServerSocketChannel serverChannel ServerSocketChannel.open(); serverChannel.configureBlocking(false); serverChannel.bind(new InetSocketAddress(port)); // 3. 将Channel注册到Selector监听ACCEPT事件 serverChannel.register(selector, SelectionKey.OP_ACCEPT); while (true) { // 4. 阻塞等待事件发生 if (selector.select(TIMEOUT) 0) { continue; } // 5. 获取就绪事件的Key集合 IteratorSelectionKey keyIter selector.selectedKeys().iterator(); while (keyIter.hasNext()) { SelectionKey key keyIter.next(); // 6. 处理事件 if (key.isAcceptable()) { // 接受新连接并将新SocketChannel注册到Selector SocketChannel clientChannel serverChannel.accept(); clientChannel.configureBlocking(false); clientChannel.register(selector, SelectionKey.OP_READ, ByteBuffer.allocate(BUFFER_SIZE)); } if (key.isReadable()) { // 读取客户端数据 SocketChannel channel (SocketChannel) key.channel(); ByteBuffer buffer (ByteBuffer) key.attachment(); int bytesRead channel.read(buffer); if (bytesRead -1) { // 连接关闭 channel.close(); } else if (bytesRead 0) { buffer.flip(); // ... 处理buffer中的数据 ... buffer.clear(); // 或 compact() // 可以改为监听写事件准备回写数据 key.interestOps(SelectionKey.OP_WRITE); } } if (key.isWritable()) { // ... 向客户端写数据 ... } // 7. 非常重要处理完后必须手动移除当前Key keyIter.remove(); } }核心要点注意代码中最后一步keyIter.remove()。selector.selectedKeys()返回的集合是一个“已选择键集”它不会自动移除处理过的Key。如果不手动移除下一次select()返回时这个已经处理过的Key还会在集合中导致程序重复处理同一个事件这是NIO编程中一个非常常见的错误。6. 反射、注解与泛型元编程与类型安全的基石这部分内容考察的是对Java语言更高级特性和设计理念的理解它们广泛应用于框架底层、代码生成和通用组件开发中。6.1 反射机制动态能力的双刃剑反射Reflection允许程序在运行时获取类的内部信息类名、方法、字段、构造器等并能动态调用对象的方法、操作字段。Class类是反射的入口。获取Class对象的三种方式Class.forName(全限定类名)最常用常用于加载数据库驱动等。类名.class字面量方式编译时已知。对象.getClass()通过实例获取。核心API与应用创建实例clazz.newInstance()已过时要求有无参构造或clazz.getDeclaredConstructor(...).newInstance(...)。调用方法clazz.getMethod(方法名, 参数类型...).invoke(对象实例, 参数值...)。操作字段clazz.getDeclaredField(字段名)然后field.setAccessible(true)突破私有限制最后field.set(对象, 值)或field.get(对象)。反射的优缺点优点灵活性极高是许多框架如Spring的IoC、MyBatis的ORM实现的基础。可以实现动态代理、插件化架构等。缺点性能开销反射调用涉及动态解析类型、方法查找、安全检查等性能远低于直接调用。在性能敏感的场景需谨慎使用或缓存Method/Field对象。安全限制可以突破私有访问限制破坏了封装性。内部暴露使得代码变得不直观调试困难。优化技巧在需要高频使用反射调用的地方如RPC框架的调用代理可以考虑使用MethodHandleJDK 7或直接生成字节码如使用CGLIB、ByteBuddy、ASM库它们的性能比传统反射高得多。6.2 注解与泛型编译时与运行时的类型艺术注解Annotation是一种元数据为代码提供信息这些信息可以被编译器、开发工具或运行时环境使用。元注解如Target,Retention,Documented,Inherited用来定义注解的行为。Retention(RetentionPolicy.RUNTIME)是框架中最常用的因为它允许在运行时通过反射读取注解信息从而实现依赖注入、事务管理、权限检查等功能。自定义注解处理器继承AbstractProcessor可以在编译期处理注解生成额外的代码如Lombok实现编译时检查或代码增强。泛型Generics提供了编译时的类型安全检查并消除了强制类型转换的麻烦。它的核心是类型参数化。关键概念与擦除类型擦除Java的泛型是伪泛型在编译后所有泛型信息都会被擦除替换为原始类型Raw Type如ListString和ListInteger在运行时都是List并在必要处插入强制类型转换。这是为了兼容JDK 5之前的代码。通配符?无界通配符表示可以接受任何类型但只能读取出的对象是Object不能写除了null。? extends T上界通配符表示类型是T或其子类。适合生产者Producer只能从中读取数据读出的类型是T不能写入除了null。? super T下界通配符表示类型是T或其父类。适合消费者Consumer只能向其中写入T类型的数据读取时只能得到Object。PECS原则Producer-Extends, Consumer-Super这是使用通配符的黄金法则。当你需要一个数据结构来提供生产元素时使用extends当你需要一个数据结构来接收消费元素时使用super。例如Collections.copy(List? super T dest, List? extends T src)方法就完美体现了这一原则src是生产者用extendsdest是消费者用super。理解泛型擦除有助于解释一些现象比如不能创建泛型数组new T[]因为运行时不知道T的具体类型也不能用instanceof检查泛型类型list instanceof ListString是错误的。这些限制都需要在编码时特别注意。