可具体化类型前几篇已介绍了泛型擦除、参数化类型以及原始类型的相关概念，但对于部分结论的阐述仍存在一些模糊之处——例如，为什么具体参数化类型的数组无法创建，而原始类型或无界通配符参数化类型的数组却允许创建（尽管这种用法并不推荐）。 在此，对这一问题进行系统整理：所有能够创建数组的类型，本质上都是可具体化类型（reifiable type）。所谓可具体化类型，指的是一种在程序运行时能够被JVM完全识别

泛型类型定义的限制在上一篇中，我们提到参数化类型的使用存在一些限制：无法创建参数化类型的数组、无法作为异常类型、无法作为类型字面量（如List<String>.class）、无法用于instanceof关键字的类型判断。 这里需要注意区分一个易混淆的概念：泛型类型定义时的限制，即定义泛型类型时，不可以将哪些特殊类作为泛型类。具体来说，泛型类型不能是枚举类、匿名内部类、异常类型。 枚举

泛型擦除Java泛型是编译时（compile time）行为，在运行时（runtime）所有与泛型相关的信息都会被彻底擦除。擦除后，所有参数化类型都会统一还原为同一个原始类型（raw type）。这里引入一个新术语——原始类型，指的是泛型类 / 接口去掉所有泛型类型参数后的基础类型，也是泛型类型经过类型擦除后，JVM在运行时实际识别的类型。 12345System.out.println

Java泛型是众多开发者面临的难点，尤其是涉及通配符的场景。许多开发者往往看得懂却写不出，在选择合适通配符时更是困惑不已。 本文整理自Angelika Langer关于Java泛型的探讨。泛型本身属于复杂议题，本系列无法涵盖所有细节，仅聚焦于易混淆且实战中高频使用的核心特性。建议读者具备基础泛型知识后，再阅读本文以提升理解效率。 术语首先，需统一梳理泛型相关的核心术语。在阅读泛型代码时，明确各元素

今天，总算给设计模式系列画完了句号。回头看，这个系列的第一篇文章Design-Pattern-Relationships-Between-Objects是2023年6月12日发的，一晃已经过去两年半了。 这两年半的工作里，经验慢慢攒了些，心里也慢慢冒出了困惑：咱们深耕技术的价值，到底在哪儿呢？职场里仿佛是“业务为王”的天下，所有人都围着业务转，技术反倒成了无人问津的小透明。就连技术人自己，好像也总

访问者模式（Visitor）是一种行为型设计模式。其核心思想在于：分离数据结构与数据操作，支持在不修改现有数据结构的前提下，为其扩展新的操作逻辑。 场景假设需开发一款办公文档处理程序，该文档由多种核心元素构成，具体包括标题、段落、文本、图片等。基于上述各类元素的共性特征，设计并定义了元素接口Element，各类具体元素均为该接口的实现类。 当前需对这些元素执行一系列操作，例如元素导出、格式转换、内

模板模式（Template Pattern）是一种行为型设计模式，其核心思想是：在抽象父类中定义一个操作的算法骨架（模板），将部分步骤的具体实现延迟到子类中完成。通过这种方式，子类可以在不改变算法整体结构的前提下，重新定义算法中的某些特定步骤。 场景假设需要生成三种格式的报表（PDF/Excel/HTML），初始方案简单定义了三个独立类分别处理数据生成与报表渲染。 1234567891011121

策略模式（Strategy Pattern）是一种行为型设计模式，它定义了一系列算法（策略），并将每个算法封装起来，使它们可以互相替换，且不影响客户端的使用。 场景在日常生活中，做一件事通常有多种方式。例如点外卖时，可以选择距离优先，好评优先对商家进行排序。从代码开发角度，如果存在多种排序规则，则可以定义一个排序方法，接受排序规则作为入参，一段典型的代码如下： 12345678910public

状态模式是一种行为设计模式，它允许对象在其内部状态改变时改变它的行为，对象看起来好像修改了它的类。 场景笔者曾基于按键精灵开发过一些自动化软件，用于在PC端及移动设备上模拟用户点击与输入操作，从而自动完成游戏内的日常任务。其底层实现逻辑为：程序通过一个持续运行的死循环，定时截取当前屏幕画面，基于图像特征判断当前所处的游戏界面状态（如主菜单、战斗中、战斗结束等），随后依据预先配置的操作策略，执行对应

观察者模式是一种行为设计模式，允许定义一种订阅机制，可在对象事件发生时通知多个“观察”该对象的其他对象。 场景在开发中，经常会使用异步任务，来处理耗时的操作（如网络请求、数据库查询、文件读写等I/O密集型任务）。由于任务实际耗时与完成时机不确定，若发起方需关注结果，可以通过以一定频率主动查询的方式获取处理状态，这种方式也被称为轮询（polling）。也可以由处理方，在结束后主动通知任务发