1.1 Java开发的定义、核心优势与典型应用场景
我经常被刚入行的朋友问到，Java开发到底是做什么的。这个问题看起来简单，真正说清楚却要花点功夫。从我的理解来看，Java开发是以Java语言为核心工具，围绕业务需求完成软件设计、编码、测试、部署和维护的一系列工程活动。它不单单是写代码，更多时候是在解决实际问题——把复杂的业务逻辑翻译成计算机能执行的指令，同时保证系统稳定、高效、可扩展。
Java能流行这么多年，核心优势摆在那里。跨平台能力是它最早的杀手锏，“一次编写，到处运行”这句话我入行时就听说了，JVM这层抽象让Java程序跟操作系统解耦，企业不用为不同环境维护多套代码。生态成熟度也是关键，从Web开发到大数据、Android、中间件，几乎所有主流技术领域都有Java的身影。还有一个容易被忽略的优势：社区庞大、资料丰富。遇到问题搜一下，大概率能找到答案，这对开发者来说太重要了。
典型应用场景方面，我接触过的项目里，企业级后端系统是Java最主力的战场。银行、电商、政务平台，这些对稳定性要求极高的系统，大量采用Java构建。电商大促时每秒几十万笔订单，背后往往是Java服务在支撑。Android应用开发早期几乎全靠Java，现在虽然Kotlin崛起，大量存量项目仍然在用Java维护。大数据领域更明显，Hadoop、Spark、Flink这些框架都是用Java或基于JVM的语言写的。还有中间件开发，像消息队列、缓存系统，Java也占据重要位置。这些场景共同点是：高并发、高可靠、长周期维护，恰好是Java的强项。
1.2 Java开发岗位分类与能力模型
打开招聘网站搜“Java开发”，出来的岗位五花八门。我习惯把它们分成几类来看。后端开发工程师是数量最多的，主要负责服务端业务逻辑、接口设计和数据库交互。这类岗位对Spring生态、数据库、并发编程要求比较高。大数据开发工程师是另一个方向，需要掌握Hadoop、Spark这些工具，Java是基础语言但更侧重数据处理能力。Android开发工程师现在虽然少了，但存量岗位还在，需要了解移动端特性和UI框架。还有中间件开发、架构师、技术专家等更高级的方向，对底层原理和系统设计能力要求更高。
能力模型这件事，我跟团队里不同级别的同事聊过很多次。初级岗位看重基础语法、面向对象理解、简单框架使用，能按要求完成功能模块就行。到了中级，要求就上来了——得懂JVM内存模型、能排查线上问题、会做数据库优化、理解常用设计模式。高级工程师需要具备系统设计能力，能拆解复杂需求、做技术选型、带小团队攻坚。架构师层面则要站在业务全局思考，平衡技术债务和业务迭代，设计出可演进的系统架构。每个级别之间不是简单的知识量累加，而是思维方式的跃迁。
我自己的体会是，能力模型里软技能常常被低估。沟通能力决定了你能不能准确理解需求，文档能力影响团队协作效率，技术分享能力则关系到个人影响力。技术硬实力是基础，但走得远的人，往往是在软技能上也不短板的那批。招聘时我看重候选人能否清晰表达自己的项目，能不能把技术决策背后的权衡讲明白，这些比多背几道面试题更有说服力。
1.3 Java开发者成长阶段与总学习路径
回顾我带过的新人和自己走过的路，Java开发者的成长大致可以分成四个阶段。第一个阶段是入门期，通常三到六个月，目标是能独立写出可运行的小程序，理解面向对象基本概念，会用IDE和Git。这个阶段最怕的是贪多嚼不烂，有人一上来就想学分布式，连集合框架都没搞明白，后面很容易卡住。第二个阶段是成长期，大概一到两年，重点是把Java核心技术吃透，集合、IO、多线程、JVM基础都要过一遍，同时开始接触Spring Boot做项目。
第三个阶段我称为突破期，通常两到四年经验。这个阶段的关键词是深度和广度并重。深度上要能读懂框架源码、理解设计思想，广度上要接触分布式、消息队列、缓存、容器化这些工程实践。很多人卡在这个阶段，因为从“会用”到“懂原理”需要大量刻意练习。第四个阶段是成熟期，五年以上，重点转向架构设计、技术决策和团队赋能。这时候写代码的时间可能少了，但每个决策影响的范围更大了。
总学习路径的设计，我建议遵循“核心稳定、外围渐进”的原则。Java语法、面向对象、集合、并发、JVM这些是核心，值得反复打磨，基础不牢后面会还债。Spring、数据库、分布式这些是外围，随着工作需求逐步深入。学习节奏上，我见过进步最快的同行，都是保持每周固定时间输入和输出的人。输入是看源码、读文档、学课程，输出是写博客、做分享、参与开源。光输入不输出，知识留存率很低。还有一个容易被忽视的点：定期回顾和复盘。每学完一个模块，回头看看之前的理解有没有偏差，这种自我修正的能力，比单纯堆学习时长重要得多。
2.1 入门阶段：开发环境、基础语法与面向对象
我带过好几个完全零基础转行的朋友，他们问的第一个问题几乎都是：从哪开始？我通常会说，先把环境搭起来。这件事听起来简单，但真动手的时候坑不少。JDK版本的选择就够让人纠结一阵，有人装了最新版结果发现公司项目跑的是Java 8。我的建议是装JDK 8和JDK 17两个版本，通过环境变量切换，这样既能兼容老项目也能体验新特性。IDE方面IntelliJ IDEA社区版免费够用，Maven负责依赖管理，Git做版本控制，这三个工具配齐基本就能开工了。环境变量配置是个考验耐心的事，JAVA_HOME、PATH、CLASSPATH这几个变量的含义我当初花了大半天才弄明白。能独立把一个Hello World跑起来，输入javac和java命令不报错，这一步就算过了。
语法学习阶段，变量、数据类型、运算符、流程控制这些内容，任何一本入门书都会讲。我看过很多新手的学习方式——对着教程敲代码，敲完运行没问题就翻篇。这种方式效率其实很低。我的做法是每学一个语法点，就自己出一道小题目来练。比如学完for循环，试着打印一个九九乘法表；学完数组，写一个学生成绩统计的小程序。这个过程会逼着你去思考边界情况，比如数组越界怎么处理、循环条件写错了会怎样。错误信息读多了，调试能力自然就上来了。基础语法里我觉得最值得花时间的是字符串处理和数组操作，这两块在后续开发中出现的频率极高。
面向对象是入门阶段真正的分水岭。类、对象、封装、继承、多态这几个概念，光看定义很容易，用起来完全是另一回事。我见过不少人学完语法后写出来的代码全是main方法里堆过程式逻辑，类只是用来装方法的壳子。要突破这一关，我建议从模仿真实场景开始。比如设计一个动物园系统，Animal作为父类，Dog、Cat继承它，每个子类重写makeSound方法。写完之后再想想，如果把Animal设计成接口会怎样，抽象类又有什么区别。这种对比练习做多了，对面向对象思想的理解会深刻很多。封装这件事我特别想多说一句，很多新手习惯把所有字段都设成public，觉得省事。等到项目变大，改一个字段影响几十个地方的时候，就知道private加getter/setter的价值了。
2.2 进阶阶段：集合、异常、IO、多线程与JVM入门
集合框架是我认为Java基础里性价比最高的部分。ArrayList和LinkedList的区别、HashMap的底层结构、ConcurrentHashMap怎么保证线程安全，这些知识点面试必问，工作中也天天用。我当初学HashMap的时候，看完哈希冲突和扩容机制的理论，自己动手画了好几遍图才真正记住。后来看到JDK 8把链表转红黑树的优化，又回头把源码翻了一遍。我的经验是，集合这块不能只停留在会用的层面。知道什么时候该用TreeMap而不是HashMap，明白ArrayList扩容为什么是1.5倍，这些细节决定了你写出来的代码是能用还是好用。泛型是配合集合使用的，通配符? extends和? super的区别我用了很久才搞清楚，建议结合Collections工具类的方法签名来理解。
异常处理这块，我踩过的坑比想象中多。刚开始写代码时，遇到编译错误就随手try-catch包起来，catch块里打印个e.printStackTrace()就算完事。后来线上出了问题，日志里全是堆栈信息，根本定位不到业务上下文。自定义异常是个好习惯，BusinessException配上错误码和描述信息，排查问题时效率高很多。try-with-resources语法在JDK 7之后就有了，操作文件流或者数据库连接时自动关闭资源，比手动在finally里写close优雅得多。IO部分，字节流和字符流的转换、缓冲流的使用、NIO的Channel和Buffer概念，这些内容初学时会觉得杂，但做文件上传下载、网络通信的时候全用得上。我建议把IO和NIO放在一起对比学习，理解阻塞和非阻塞的差异。
多线程是进阶阶段最硬的一块骨头。Thread和Runnable的写法不难，难的是理解线程安全。synchronized加在方法上和加在代码块上有什么区别，volatile为什么不能保证原子性，AtomicInteger底层用的CAS是什么原理，这些问题我当初查了很多资料才理顺。线程池的使用算是多线程入门的标志，ThreadPoolExecutor那几个核心参数——核心线程数、最大线程数、队列容量、拒绝策略——每个都值得单独研究。我见过有人用Executors.newFixedThreadPool创建线程池，结果队列无界导致内存溢出，这就是没理解参数含义的后果。JVM入门可以从内存区域划分开始，堆、栈、方法区各自存什么，对象创建的过程是怎样的。垃圾回收这块先了解分代收集的思想和几种常见的GC算法就够了，深入调优可以放到后面。
2.3 框架阶段：Spring、Spring Boot、MyBatis与微服务基础
从纯Java过渡到框架，很多人会有一段不适应期。Spring的核心是IoC和AOP，这两个概念干讲很抽象。我的建议是先不用Spring，用最原始的方式写一个依赖注入的例子——手动new对象、手动传依赖——然后再看Spring怎么帮你做这件事。理解了自己管理对象的痛苦，才能体会到IoC容器的价值。AOP也一样，先想想哪些逻辑是横切关注点，比如日志、事务、权限校验，这些代码散落在各个业务方法里维护起来有多麻烦，再去看Spring怎么通过动态代理把这件事优雅地解决掉。Bean的生命周期和作用域是面试高频考点，我当初把单例Bean的创建过程画了一张流程图贴在工位上，看了很多遍才记住。
Spring Boot的出现大幅降低了Spring的使用门槛。自动配置、起步依赖、内嵌容器这三个特性让搭建一个Web项目变得异常简单。我刚开始用Spring Boot的时候，被各种starter搞晕了头，后来看懂了spring.factories和条件注解的机制，才明白自动配置是怎么回事。写一个自定义starter是很好的练习，能帮你理解Spring Boot的扩展点。MyBatis作为持久层框架，核心是SQL映射和动态SQL。XML配置文件和注解两种方式各有适用场景，复杂查询用XML更清晰。MyBatis-Plus在MyBatis基础上做了增强，单表CRUD几乎不用写SQL，但多表关联查询还是得老老实实写XML。我建议先学好原生MyBatis，再去看MyBatis-Plus，基础扎实了用什么工具都顺手。
微服务基础这块，我倾向于把它放在框架阶段的末尾。Spring Cloud全家桶包含的组件很多，Eureka做服务注册发现、Ribbon做负载均衡、Feign做声明式调用、Hystrix做熔断降级。初学的时候不用全部深入，先把服务注册发现和远程调用这两个核心概念跑通。我见过一些新手，Spring Boot还没用利索就开始搭微服务，结果服务拆分了但每个服务内部代码写得一团糟，这种为了微服务而微服务的做法意义不大。微服务的本质是解决单体应用在团队规模扩大后的协作问题，如果项目本身没那么复杂，单体应用反而是更合理的选择。学习微服务的时候，多想想它解决了什么问题、引入了什么新问题，这种思考比记住几个注解配置更有价值。
2.4 项目实战：需求分析、数据库设计、接口开发与部署
真正让我成长最快的，是完整地做一个项目。教程里的项目通常是功能点驱动，今天写登录明天写订单，缺乏整体视角。我的建议是找一个真实的需求，哪怕很简单，比如个人记账系统或者图书管理系统，从零开始走完全流程。需求分析阶段要做的事比想象中多，用户要记账，记什么账、收入支出怎么分类、要不要支持多账户、数据要不要导出，这些问题在动手写代码之前就得想清楚。我习惯用思维导图把功能点拆解成树状结构，然后再排优先级，区分核心功能和锦上添花的功能。这个习惯帮我避免了很多次做到一半发现需求没想明白的尴尬。
数据库设计是项目实战中最考验功底的部分。表结构设计得好，后续开发顺风顺水；设计得差，写到后面全是补丁。我习惯先用纸笔画出实体关系图，用户、账户、交易记录这些实体之间是一对多还是多对多，关联字段放在哪张表里，这些想清楚了再动手建表。字段类型的选择也有讲究，金额用DECIMAL不用FLOAT，时间用DATETIME不用VARCHAR，状态用TINYINT加枚举注释。索引的创建要结合查询场景，经常作为查询条件的字段建索引，但也不能滥用，索引多了写入性能会下降。我当初做一个电商练手项目，订单表一开始没加索引，数据量到十万条的时候查询明显变慢，加上合适的索引后响应时间从秒级降到毫秒级，那次体验让我真正理解了索引的重要性。
接口开发环节，RESTful风格现在基本是标配。URL设计要见名知意，GET查POST增PUT改DELETE删，状态码要规范使用。参数校验用Hibernate Validator注解，业务异常用全局异常处理器统一返回格式，日志用SLF4J加上logback配置。这些工程化的细节在教程里往往一笔带过，但在实际工作中决定了代码的可维护性。部署环节，我建议至少走一遍手动部署的流程。用Maven打成jar包，通过scp传到服务器，用nohup启动，看日志确认服务正常运行。Docker出现后部署简单了很多，写一个Dockerfile把应用打包成镜像，一条命令就能跑起来。Nginx做反向代理和负载均衡的配置也值得亲手写一遍，理解请求从浏览器到后端服务的完整链路。项目做完之后，回头把代码重构一遍，抽取出重复代码、优化命名、补充注释，这个过程比写新功能的收获更大。
2.5 学习路线常见误区与阶段目标检验
我见过太多人在学习路上走偏。最普遍的一个误区是收集资料成瘾，网盘里存了几十个G的视频和PDF，真正看完的没几个。还有人陷入教程循环，Java基础教程看完看进阶，进阶看完看框架，每个教程都从头跟到尾，但从来没有独立写过一个完整项目。我的观点是，教程看一个就够了，关键是动手。看视频的时候觉得什么都懂，自己写的时候发现连一个分页查询都写不利索，这就是眼高手低的典型表现。另一个误区是追求新技术而忽视基础，Spring Cloud Alibaba刚出来就急着学，JVM内存模型和并发编程却没搞明白，地基没打牢，楼越高越危险。
阶段目标的检验方法，我习惯用输出倒逼输入。入门阶段检验标准很简单：能不能独立完成一个控制台版的图书管理系统，用到面向对象、集合、异常处理、文件IO这些知识点。进阶阶段的检验标准是能写一个多线程的爬虫或者文件批量处理器，理解线程池参数的含义，能分析简单的OOM问题。框架阶段的检验标准是独立搭建一个Spring Boot项目，整合MyBatis实现增删改查，接口符合RESTful规范，能处理全局异常。项目实战阶段的检验标准是把项目部署到服务器上，通过域名或者IP能访问，数据库连接池、日志、缓存这些配置都调通。每个阶段的目标不用定得太高，但必须能拿出可运行、可演示的东西。
学习节奏这件事，我越来越觉得质量比数量重要。有人每天花五六个小时看视频，但从来不敲代码，这种学习效果很差。我自己保持的习惯是，每天至少写一百行有效代码，不是复制粘贴，是自己思考后敲出来的。遇到问题先自己查资料解决，实在搞不定再问人，这个挣扎的过程才是真正长本事的时候。复盘也很关键，每完成一个阶段，花半天时间回顾一下哪些地方卡住了、哪些知识点当时理解了后来又忘了，把这些记录到笔记里。我到现在还保持着写技术博客的习惯，把踩过的坑和解决方案记下来，一方面加深自己的理解，另一方面也帮到了不少后来者。学习Java没有捷径，但有方法，找对方法能少走很多弯路。
3.1 Java基础语法与面向对象编程核心
我刚开始写Java代码那会儿，总觉得语法规则太琐碎。变量命名不能用数字开头，类型转换有时候会丢精度，i++和++i在表达式里的行为还不一样。这些细节单独看都不难，凑在一起写业务逻辑的时候就容易翻车。印象最深的一次，我在一个金额计算里用了float，结果累加几百次之后小数点后几位开始漂移，排查了大半天才想起来该用BigDecimal。基础语法像地基，平时感觉不到它的存在，一旦出问题就是连锁反应。我现在的习惯是，每学一个语法点就顺手查一下它的边界情况，比如整数溢出、自动装箱拆箱的缓存范围、switch对字符串的支持版本。这些东西面试官爱问，代码里也真的会踩坑。
面向对象编程的核心，我理解成一句话：让代码的职责归位。类应该只做一件事，方法应该只做一件事，依赖关系要清晰可替换。封装不只是把字段改成private加getter/setter，而是对外暴露最小的接口，隐藏内部实现细节。继承用多了容易导致父类一改子类全崩，我后来更倾向于组合优先。多态的价值在框架里体现得最明显，Spring的依赖注入、MyBatis的Mapper代理，底层都靠接口和多态支撑。抽象类和接口的选择，我自己的判断标准是：如果多个实现共享状态或默认行为，用抽象类；如果只是定义一组契约，用接口。这个判断不一定绝对，但能帮我快速做决定。
设计类的时候，我会刻意去想“这个类三个月后还能不能看懂”。命名要能表达意图，方法参数不要超过四个，长方法拆成小步骤。我见过太多把业务逻辑堆在一个Service方法里几百行的代码，读起来像解密。面向对象不是背概念，是在每一次写类、写方法的时候问自己：这个职责该由谁承担？依赖关系是不是单向的？改一个地方会不会牵动全身？这些问题想多了，代码质量自然往上走。我到现在还会翻《Effective Java》和《重构》，每次看都有新的体会，因为写得越多，越能理解那些原则背后的代价。
3.2 集合框架、泛型、Lambda与Stream API
集合框架是我认为Java基础里最值得反复琢磨的部分。ArrayList和LinkedList的区别不只是数组和链表，还有随机访问和插入删除的性能取舍。HashMap的哈希冲突处理、扩容机制、红黑树转换阈值，这些底层细节决定了你在高并发场景下该不该用它。我一开始用HashMap从来不看源码，直到有一次线上CPU飙高，发现是哈希碰撞严重导致链表过长。后来我把HashMap和ConcurrentHashMap的源码都过了一遍，才算真正理解为什么ConcurrentHashMap在JDK 8里放弃了分段锁。集合的选择没有银弹，TreeMap适合排序场景，LinkedHashMap适合保持插入顺序，CopyOnWriteArrayList适合读多写少。知道每个集合的适用边界，比背API有用得多。
泛型解决的是类型安全问题，但通配符? extends和? super我花了很久才理顺。记住PECS原则——生产者用extends，消费者用super——能在写工具类的时候少犯错。Lambda和Stream API让集合操作变得优雅，一行代码就能完成过滤、映射、排序、归约。我刚开始用Stream的时候，什么操作都往上套，后来发现简单循环反而更直观。Stream的惰性求值特性意味着中间操作不会立即执行，终端操作触发时才走一遍流水线。并行流要慎用，线程池默认是ForkJoinPool.commonPool，里面如果混了阻塞操作，整个应用的并行能力都会受影响。我一般在数据量大、操作无状态、不涉及IO的时候才考虑并行流。
泛型和Lambda结合，能写出非常灵活的代码。函数式接口Function、Consumer、Supplier、Predicate在框架里到处都是，理解它们等于拿到了阅读源码的钥匙。Stream的collect方法配合Collectors工具类，分组、分区、聚合都能搞定，但代码可读性会下降，我通常会把复杂的Stream操作抽成单独的方法并加上注释。集合框架和Stream API是日常开发中使用频率最高的部分，我的建议是每个集合类都亲手写一遍增删改查和遍历，每个Stream中间操作都跑一个最小示例，看到输出结果才算真正掌握。
3.3 多线程、并发工具与线程安全实践
多线程是我学Java过程中最头疼的一块，也是面试区分度最高的地方。创建线程的方式有继承Thread、实现Runnable、实现Callable配合线程池，实际项目里几乎都用线程池。ThreadPoolExecutor的七个参数——核心线程数、最大线程数、空闲存活时间、时间单位、工作队列、线程工厂、拒绝策略——每个都值得单独研究。我踩过最大的坑是用Executors.newFixedThreadPool创建线程池，队列是无界的LinkedBlockingQueue，任务积压导致内存溢出。后来我养成了习惯，所有线程池都手动new ThreadPoolExecutor，根据业务场景设置队列容量和拒绝策略。
线程安全的核心是共享可变状态的控制。synchronized能保证原子性和可见性，但锁的粒度要控制好，锁方法还是锁代码块，锁对象还是锁类，结果完全不同。volatile保证可见性和禁止指令重排，但不保证原子性，这一点我当初用i++测试了很久才记住。AtomicInteger底层用CAS实现，适合计数器场景，但高并发下CAS自旋会消耗CPU。ReentrantLock比synchronized灵活，支持公平锁、可中断、超时获取，但必须手动释放锁。并发工具类里，CountDownLatch适合等待多个任务完成，CyclicBarrier适合多轮同步，Semaphore控制并发访问数量。这些工具在压测和批量处理场景里特别有用。
线程安全的实践，我总结下来就是三招：不可变对象、线程封闭、同步控制。String、Integer这些不可变类天生线程安全，能多用就多用。ThreadLocal做线程封闭，每个线程有自己的副本，但用完一定要remove，否则线程池复用时会内存泄漏。同步控制能少用就少用，锁的范围越小越好，能无锁就无锁。我排查过几次线上死锁，都是因为两个线程互相持有对方需要的锁，用jstack导出线程栈才定位到。并发编程没有捷径，多写多调试，遇到问题先看线程状态和锁持有情况，经验慢慢就攒出来了。
3.4 JVM内存模型、垃圾回收与性能调优基础
JVM内存模型把运行时数据区划分成堆、虚拟机栈、本地方法栈、方法区、程序计数器。堆是垃圾回收的主战场，方法区在JDK 8以后由元空间实现，使用本地内存。对象创建的过程包括类加载检查、分配内存、初始化零值、设置对象头、执行构造方法。这些步骤在面试里经常被追问，我当初把《深入理解Java虚拟机》那本书翻了三遍，每次都有新收获。栈帧里存局部变量表、操作数栈、动态链接、方法返回地址，理解栈帧结构对分析递归深度和栈溢出很有帮助。内存分配策略有指针碰撞和空闲列表两种，取决于垃圾收集器是否具备压缩整理能力。
垃圾回收的核心是判断对象是否存活。引用计数法有循环引用问题，Java用的是可达性分析，从GC Roots出发标记存活对象。垃圾收集算法有标记清除、标记复制、标记整理，各有优缺点。分代收集理论把堆分成新生代和老年代，新生代用复制算法，老年代用标记清除或标记整理。垃圾收集器从Serial、Parallel、CMS发展到G1、ZGC，停顿时间越来越短，吞吐量也在提升。我现在的项目里用G1比较多，可以通过-XX:MaxGCPauseMillis设置目标停顿时间，但实际效果要看对象分配速率和存活对象大小。CMS在JDK 9之后被标记为废弃，新项目不建议再用。
性能调优的基础是监控和日志。jps看Java进程，jstat看GC统计，jmap看堆内存快照，jstack看线程栈，jinfo看JVM参数。可视化工具里VisualVM和JConsole能直观看到内存和CPU曲线，Arthas在线上环境特别好用，可以动态查看方法调用、反编译类、监控耗时。我处理过一次堆内存泄漏，用jmap导出快照，再用MAT分析引用链，发现是一个静态Map一直在往里面放对象，没有清理。调优不是调参数那么简单，先定位问题再动手，盲目调参可能让问题更隐蔽。平时多关注GC日志，看看Full GC频率和耗时，心里对应用的运行状态就有数了。
3.5 异常处理、IO/NIO与网络编程
异常处理看起来简单，写好其实不容易。Java的异常体系分Error、Exception、RuntimeException，受检异常必须捕获或声明抛出，非受检异常不强制。我刚工作时喜欢用try-catch把整段代码包起来，然后printStackTrace，后来发现线上日志里堆栈信息没有业务上下文，根本定位不到问题。自定义异常是个好习惯，带上错误码和描述信息，用全局异常处理器统一返回格式。try-with-resources在JDK 7之后自动关闭资源，比在finally里手动close安全得多。异常不要用来控制流程，创建异常对象有性能开销，而且会让代码逻辑变得混乱。我现在的原则是：能预判的错误用返回值处理，真正的异常情况才抛异常。
IO和NIO的区别在于阻塞和非阻塞。传统IO基于流，字节流和字符流分别处理二进制和文本数据，缓冲流能减少系统调用次数。NIO基于通道和缓冲区，Channel是双向的，Buffer负责数据读写，Selector实现多路复用。文件操作我用Files工具类比较多，一行代码就能读写整个文件。网络编程里，Socket和ServerSocket是阻塞式的，一个连接一个线程；NIO的Selector可以用一个线程管理多个连接，适合高并发场景。Netty在NIO基础上做了封装，解决了很多细节问题，比如粘包拆包、心跳检测、编解码。我写过一个简单的NIO聊天室，理解SelectionKey的四种事件——OP_ACCEPT、OP_CONNECT、OP_READ、OP_WRITE——对掌握网络编程很重要。
IO和网络编程的知识点很散，但都是实际项目里绕不开的。文件上传下载要处理流和缓冲区，RPC调用要理解序列化和网络传输，HTTP客户端要处理连接池和超时。我的学习方法是先写一个简单的文件拷贝程序，然后用NIO重写一遍，再写一个基于Socket的多人聊天，最后用Netty改写。每次重写都会暴露新的问题，比如NIO的ByteBuffer读写切换要调用flip和clear，忘记调用就会读到脏数据。网络编程调试起来比较麻烦，我一般会先用telnet或nc测试端口连通性，再用Wireshark抓包分析。这些工具用熟了，排查网络问题会快很多。
4.1 Spring生态与Spring Boot快速开发
我最早接触Spring的时候，还要写一堆XML配置文件。一个applicationContext.xml里塞满了bean的定义，改一个类的包名，得去XML里同步改三处。那时候我特别不理解依赖注入到底好在哪，觉得new对象明明更直接。直到我接手了一个二十多个模块的老项目，需要给某个Service统一加日志和事务，用AOP切面几行代码就搞定了，我才真正体会到Spring的价值。它把对象的创建、装配、增强都从业务代码里抽了出来，让开发者只需要关注业务本身。
Spring Boot出现之后，开发体验变化很大。起步依赖把常用的库打包到一起，版本冲突少了很多。自动配置靠@ConditionalOnClass、@ConditionalOnMissingBean这些条件注解，在启动时判断该装配哪些Bean。我研究过spring-boot-autoconfigure里的源码，发现很多自动配置类都预留了@ConditionalOnProperty开关，理解这个机制之后，我就能自己写Starter给团队内部复用。写Starter有个小技巧，META-INF/spring.factories在Spring Boot 3之后改成了META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports，踩过一次坑之后印象特别深。
日常开发里我用得最多的是@RestController、@Service、@Transactional、@ConfigurationProperties这几组注解。@Transactional有几个失效场景值得反复提醒自己：同类内部方法调用不走代理、异常被catch住不抛出、方法不是public、数据库引擎不支持事务。我在项目里见过有人把@Transactional加在private方法上，测了半天发现回滚没生效。配置文件方面，我用application-{profile}.yml区分环境，敏感信息走环境变量或者配置中心。Spring Boot的CommandLineRunner和ApplicationRunner适合做启动初始化，但要注意别在里面写耗时太长的逻辑，会拖慢服务启动。
4.2 数据访问：JDBC、MyBatis、JPA与数据库优化
刚学Java那阵子，我用JDBC写过一个学生管理系统。Class.forName加载驱动，DriverManager.getConnection拿连接，PreparedStatement执行SQL，ResultSet遍历结果，每一步都要手动关资源。写得多了就发现，连接创建和销毁的开销特别大，一个页面请求要跑好几次数据库，性能很难看。连接池就是来解决这个问题的，HikariCP现在基本是默认选择，它的maximumPoolSize、connectionTimeout、idleTimeout几个参数要根据数据库承载能力和业务并发量来调。池子开太大，数据库扛不住；开太小，请求排队。我一般会结合压测结果来定，不会凭感觉填数字。
MyBatis是我在项目里用得最多的ORM框架。它把SQL和Java代码解耦，XML里写SQL，接口里定义方法，映射关系清晰。动态SQL的<if>、<foreach>、<choose>在写多条件查询时特别方便。我踩过#{}和${}的坑，前者是预编译参数，后者是字符串拼接，用${}拼order by字段的时候如果有外部输入，会有SQL注入风险。JPA和Hibernate我更倾向于在领域模型相对稳定、查询不太复杂的场景使用，它的缓存机制和懒加载能省不少代码，但N+1查询问题很隐蔽。我排查过一次接口响应慢，打开SQL日志发现一个列表查询背后跑了几百条SQL，就是因为懒加载在循环里被触发。
数据库优化这块，我总结下来是三层：SQL层面、索引层面、架构层面。SQL层面看执行计划，explain出来的type、key、rows、Extra字段能说明很多问题，Using filesort和Using temporary通常意味着需要优化。索引不是越多越好，写操作多的表索引太多会拖慢插入和更新速度，联合索引要遵循最左前缀原则。分页查询在深分页的时候limit 100000, 20会很慢，可以用游标或者子查询优化。架构层面就是读写分离、分库分表、缓存。这些手段都有代价，读写分离会带来主从延迟，分库分表会让分布式事务变复杂，缓存会引入一致性问题。选方案之前先想清楚业务能容忍什么，不能容忍什么。
4.3 微服务架构、Spring Cloud与API设计
我从单体应用拆到微服务，是被业务逼的。一个电商系统早期所有功能都在一个war包里，发布一次要停服十分钟，小团队改一个优惠券逻辑要重新回归整个系统。拆分之后，每个服务独立部署、独立扩缩容，团队之间的耦合也降低了。代价是运维复杂度上来了，一个请求要跨好几个服务，出问题排查起来像破案。我印象最深的一次线上故障，订单服务超时，查了半天发现是库存服务的数据库连接池被打满，链路上一环卡住，整条链路都受影响。
Spring Cloud生态里，注册中心、配置中心、网关、负载均衡、熔断限流是几个核心组件。早期用Eureka加Ribbon，后来Nacos和Spring Cloud LoadBalancer用得更多。网关用Spring Cloud Gateway，可以做鉴权、限流、路由转发、请求日志。OpenFeign声明式调用写起来很舒服，接口定义像本地方法一样，但要注意超时配置、重试策略和降级逻辑。Sentinel和Resilience4j都能做熔断限流，Sentinel的控制台更直观，规则可以动态推送。链路追踪我用过SkyWalking和Zipkin，能把一次请求经过的所有服务串联起来，定位性能瓶颈的时候特别有用。
API设计是微服务里容易被忽视的一环。RESTful风格强调资源导向，URL用名词复数，HTTP方法表达动作，状态码表达结果。实际项目里完全符合REST的接口不多，很多团队会用POST /order/create这种风格，能跑通业务就行，不必为了规范而规范。接口版本管理我倾向于放在URL路径里，/api/v1/这种形式最直观。幂等性设计在支付、下单这些场景必须考虑，常用方案有唯一索引、Token机制、状态机。错误码要统一规划，业务错误和系统错误分开，前端能根据错误码做不同处理。接口文档用Swagger或者SpringDoc自动生成，改代码的时候顺手更新注解，比单独维护一份Word文档靠谱得多。
4.4 构建工具、版本控制、测试与持续集成
Maven我用了很多年，后来团队新项目转Gradle，刚开始不太适应。Maven的pom.xml结构清晰，生命周期和插件机制很好理解。Gradle用Groovy或Kotlin写构建脚本，灵活度高，构建速度也快一些，增量编译做得好。依赖冲突是构建里最常见的问题，mvn dependency:tree能打印依赖树，找到冲突的版本，用exclusions排除或者dependencyManagement统一版本。我遇到过一次线上NoSuchMethodError，本地跑没问题，打包后运行就报错，查了半天是不同模块引了同一个库的不同版本，编译期用的是A版本，运行期加载的是B版本。这种问题用mvn enforcer插件能在构建时就拦住。
Git是团队协作的基础。分支模型上，我们用过Git Flow，也用过Trunk Based Development。Git Flow适合版本发布节奏慢、需要维护多个版本的项目，TBD适合持续交付、发布频繁的团队。Commit message我坚持写清楚做了什么、为什么改，feat:、fix:、refactor:这样的前缀能让历史记录更好读。Code Review是保证代码质量的重要环节，我review别人的代码时会重点看边界条件、异常处理、事务边界、并发安全，格式问题交给工具去管。Rebase和Merge的选择看团队习惯，我个人倾向于本地分支用rebase保持整洁，合并到主干用merge保留历史。
测试和持续集成是工程化里的基本功。单元测试用JUnit 5加Mockito，一个测试方法只验证一个行为，命名用should_xxx_when_yyy这种形式，读起来像自然语言。集成测试可以用Testcontainers启动真实的MySQL和Redis容器，比H2内存数据库更贴近生产环境。CI流水线我一般分成编译、单测、代码扫描、构建镜像、部署到测试环境几个阶段，SonarQube负责静态扫描，把重复代码、潜在空指针、圈复杂度这些指标暴露出来。流水线跑得快很重要，慢的流水线大家就不爱等，会绕过流程本地直接发布。
4.5 代码规范、设计模式与可维护性提升
代码规范这件事，我觉得工具约束加团队共识比背条款更有效。阿里巴巴Java开发手册我翻过几遍，里面的命名、常量定义、集合处理、并发处理这些规约都很实用。Checkstyle、Spotless、SonarLint可以集成到IDE和CI里，格式问题自动修，不用在review的时候争论用不用tab。不过规范不是教条，我见过为了遵守"方法不超过80行"把逻辑硬拆成十几个小方法的代码，可读性反而更差。规则是为人服务的，判断标准是这段代码三个月后自己还能不能快速看懂。
设计模式我在项目里真正用得多的就那么几个。策略模式替代大段if-else，把不同支付方式、不同优惠计算抽成独立的策略类，新增一种方式只要加一个实现类。模板方法适合有固定流程、局部步骤可变的场景，比如导入文件、生成报表。责任链在审批流、参数校验、网关过滤器里很常见。单例模式看着简单，但双重检查锁定的volatile关键字漏写、静态内部类的加载时机、枚举单例的序列化安全，每个细节都能聊很久。观察者模式配合Spring的事件机制，做业务解耦很顺手，下单成功后发一条事件，积分服务、通知服务各自监听处理。
可维护性是我现在写代码时最在意的事情。一个类职责单一，一个方法只做一件事，依赖关系清晰，改起来才不会牵一发动全身。日志要打在有业务意义的地方，入参出参、关键分支、异常信息都记下来，线上排查问题的时候日志就是唯一的线索。注释写"为什么"而不是"是什么"，代码本身能说明做了什么。遗留系统改造我倾向于绞杀者模式，新功能用新写法，老代码逐步替换，一次性重写风险太大。技术债要还，但要有节奏，每次迭代留一点时间做重构，比攒到项目末期集中还债要轻松得多。写代码这件事，短期看是完成任务，长期看是在为一个团队积累资产，每一次提交都在决定这份资产是增值还是贬值。
5.1 Java基础与集合类高频面试题
我当面试官这些年，发现一个规律。基础题答得好的候选人，后面环节通常也稳。基础题答得磕磕巴巴的，大概率在并发和JVM那块也说不清楚。原因在于Java基础看着简单，背后牵扯的知识面其实很宽。一个String的问题能问到字符串常量池、intern()方法、equals和==的区别。一个Integer的问题能引到缓存范围、自动装箱拆箱、valueOf的源码实现。我见过工作五年的人答不上来HashMap的扩容机制，也见过应届生把ConcurrentHashMap的sizeCtl讲得明明白白。面试准备这件事，基础打牢了，后面怎么问都不慌。
集合类是面试里绕不开的重灾区。ArrayList和LinkedList的区别几乎每场必问，但很多人只背了“数组和链表”这一句。我倾向于追问插入删除的时间复杂度、扩容因子、随机访问的性能差异、内存占用情况。HashMap的底层结构从数组加链表进化到数组加链表加红黑树，阈值是8和64，负载因子0.75。这些数字要记住，还要能解释为什么选这些数字。我面试别人的时候喜欢让候选人画一下put的流程图，从计算哈希、定位桶、处理冲突、判断树化、扩容拆分一步步走下来。画得出来的人，对集合的理解就不会只停留在API层面。
HashMap线程不安全这个点，延伸出来就是ConcurrentHashMap。1.7版本用分段锁，1.8版本用CAS加synchronized锁单个桶。面试官问这个，想听的是你对并发安全的理解，不是背版本差异。我会顺着问Hashtable和Collections.synchronizedMap的区别，再问CopyOnWriteArrayList的适用场景。回答这些问题有个小技巧，别急着背源码细节，先给结论，再讲设计思路，最后提一句自己在项目里怎么选的。比如“我们读多写少的配置缓存用了ConcurrentHashMap，因为它的并发粒度更细”。这样回答，面试官会觉得你真正用过，不是临时抱佛脚。
5.2 并发编程、JVM与性能调优面试题
并发编程是我面试时最喜欢深挖的方向。线程状态、synchronized和Lock的区别、volatile的可见性和禁止指令重排、CAS的ABA问题、AQS的state和队列、线程池的七个参数和四种拒绝策略。这些知识点串起来能问一个小时。我遇到过一个候选人，线程池参数背得很熟，我问他“核心线程数设为多少合适”，他愣了一下说“看情况”。这个回答其实没错，但我想听的是他有没有实际调过参数。后来他讲了自己项目里用ThreadPoolExecutor做异步任务，根据QPS和任务耗时估算核心线程数，结合队列容量和拒绝策略做过压测。这个回答就很好，有场景有数据有反思。
JVM这块，面试官通常从内存区域开始问，堆、栈、方法区、程序计数器、本地方法栈。接着问对象创建过程、内存分配策略、垃圾回收算法、分代收集理论。CMS、G1、ZGC的特点和适用场景也是高频考点。类加载机制和双亲委派模型问得也很多，尤其是“如何打破双亲委派”这种开放题。我一般会追问“你线上遇到过OOM吗，怎么排查的”。这个问题能区分出真正处理过线上问题的人和只背过八股文的人。真实排查过的人会讲jmap导堆、jstack看线程栈、jstat观察GC频率、MAT分析支配树。没处理过的人会背“内存泄漏和内存溢出”的定义。我倾向于招前者，因为线上故障不会按八股文出牌。
性能调优面试题，我从不问“JVM参数怎么配”这种空泛的问题。我会给一个具体场景，比如“线上服务CPU飙到90%，你怎么定位”。好的回答会分步骤：先用top -Hp找到高CPU线程，再用jstack找到对应线程栈，判断是业务死循环、频繁GC、还是锁竞争。如果是频繁GC，再看是Young GC还是Full GC，然后查内存分配和对象存活情况。这种问题没有标准答案，面试官看的是你的排查思路和工具使用经验。我自己调优过最久的一次，是一个定时任务批量处理数据导致Full GC频繁，后来把大对象拆小、调整了新生代比例、加了分批提交，问题才解决。面试时讲这种经历，比背参数表有说服力得多。
5.3 Spring、数据库与分布式场景面试题
Spring的面试题从IoC和AOP开始，这两个概念能延伸出Bean的生命周期、循环依赖的三级缓存、事务的传播行为和失效场景、AOP的代理方式。Spring Boot的自动配置原理问得很多，@SpringBootApplication拆开是@SpringBootConfiguration、@EnableAutoConfiguration、@ComponentScan。自动配置类的加载靠spring.factories或者新版的AutoConfiguration.imports文件，条件注解控制装配。我面试时喜欢让候选人讲一下“自己写一个Starter需要做哪些事”，这个问题能考察他对Spring Boot扩展机制的理解，也能看出有没有真的动手封装过公共组件。事务那块，我会问“同一个类里方法A调用方法B，B上有@Transactional，事务会生效吗”。这个问题几乎成了必考题，答“不会”只是及格，能讲清楚代理对象、方法调用栈、事务拦截器执行时机的，才算过关。
数据库面试题围绕索引、事务、锁、优化展开。B+树为什么适合做索引，聚簇索引和非聚簇索引的区别，回表是什么，最左前缀原则，覆盖索引，索引下推。事务的ACID、隔离级别、MVCC的实现、间隙锁和临键锁。我见过候选人把隔离级别背得滚瓜烂熟，问他“可重复读级别下幻读有没有完全解决”，他就开始含糊了。MySQL在可重复读级别下通过间隙锁很大程度上避免了幻读，但没有完全杜绝。这种细节能看出一个人是死记硬背还是真正读过资料、做过实验。慢查询优化也是高频题，我会让候选人讲explain的字段含义，type从all到ref到const的优化过程，Extra里出现Using filesort和Using temporary怎么处理。
分布式场景题是高级岗位面试的分水岭。CAP理论、BASE理论、分布式锁的几种实现、分布式事务的2PC、TCC、Saga、本地消息表、最大努力通知。缓存和数据库的一致性怎么保证，延迟双删、订阅binlog、还是先更新数据库再删缓存。消息队列的幂等、顺序、堆积怎么处理。限流算法有计数器、滑动窗口、漏桶、令牌桶，熔断降级用Sentinel还是Hystrix。这些知识点单独问都不难，难的是给一个具体场景让你设计。比如“设计一个秒杀系统”，你要考虑前端限流、网关限流、服务层限流、缓存预热、库存扣减的原子性、订单异步处理、防超卖、防刷单。回答这种题，不要一上来就讲技术栈，先问清楚业务量级、一致性要求、能容忍的延迟。面试官更看重你的分析过程，而不是最终方案有多完美。
5.4 算法、数据结构与编码能力考察
算法面试是我以前最怕的环节。刚开始找工作那会儿，LeetCode只刷了几十道，面试官让写一个二叉树层序遍历，我连队列怎么用都忘了。后来痛定思痛，按标签刷了三百多道。数组、链表、二叉树、动态规划、回溯、贪心、二分查找、排序。刷题这件事，数量重要，总结更重要。每道题做完，我会记录它的解题模板、边界条件、时间复杂度、有没有更优解。比如滑动窗口的模板，先移动右指针扩大窗口，不满足条件时移动左指针缩小窗口，过程中更新答案。这个模板能解决一大类子串、子数组问题。面试时遇到陌生题，先跟面试官沟通思路，确认理解无误再动手写。写的时候注意变量命名、边界判断、空值处理。代码写完了，自己跑几个测试用例，别等着面试官提醒。
编码能力考察不只有算法题。有时候面试官会让你手写一个单例模式，或者实现一个生产者消费者模型，或者写一个LRU缓存。这些题看着简单，细节却很多。单例模式要考虑线程安全、懒加载、反射攻击、序列化破坏。生产者消费者要考虑缓冲区满了怎么办、空了怎么办、怎么唤醒、用wait/notify还是BlockingQueue。LRU缓存要结合HashMap和双向链表，get和put都要O(1)。我面试别人的时候，会特意看代码风格。方法名是否清晰、异常处理是否合理、注释是否解释了“为什么”而不是“是什么”。有个候选人写快排，变量名叫a、b、c，我看了半天才明白哪个是基准值。代码是写给人看的，面试官也是人。
准备算法面试，我的建议是分阶段。前期按专题刷，每个专题刷十到二十道，总结套路。中期做套题，模拟面试环境，限时完成。后期保持手感，每天做一两道中等题。不要只刷简单题，面试官通常出中等难度。也不要只追求Hard题，性价比不高。面试前一周，把常考的二十道题再过一遍，比如反转链表、LRU、三数之和、岛屿数量、二分查找、快速排序、合并有序链表。这些题出现的频率极高。面试中遇到完全没思路的题，别沉默，把你能想到的暴力解法说出来，再一步步优化。面试官看重的是思考过程，不是秒出答案。
5.5 项目经验表达、系统设计题与面试复盘
项目经验是面试里最能拉开差距的部分。简历上写“负责订单模块开发”，面试官会追问订单表怎么设计的、状态机怎么流转的、并发下单怎么防止超卖、分布式事务怎么处理的。准备项目经验，我推荐用STAR法则。背景是什么，任务是什么，你做了什么，结果怎么样。重点讲你个人的贡献，不要一直说“我们团队”。技术难点要提前准备好，比如“订单超时关闭”这个功能，你可以讲用延时队列、定时任务扫表、Redis过期监听三种方案的对比，你选了哪种，为什么选，遇到了什么问题，怎么解决的。结果最好量化，比如“接口响应时间从800毫秒降到200毫秒”、“支撑了日均十万订单”。数字比形容词有力量。
系统设计题通常出现在中高级面试里。设计一个短链系统、设计一个IM、设计一个feed流、设计一个分布式ID生成器。回答这类题，我习惯先问清楚需求。用户量多大、读写比例多少、QPS多少、数据量多大、一致性要求多高、能容忍多少延迟。然后从API设计开始，定义几个核心接口的入参出参。接着做数据模型设计，表结构、索引、分库分表策略。再往上是架构分层，缓存怎么用、消息队列怎么用、数据库怎么选。最后考虑扩展性和可用性，限流、熔断、降级、监控、告警。面试官不会要求你设计得像生产系统一样完美，他想看的是你有没有结构化思考的能力，能不能在约束条件下做权衡。有个候选人设计短链系统，一上来就说用Redis存映射，我问他数据量上亿怎么办、Redis内存不够怎么办、缓存穿透怎么办，他想了很久说没考虑过。这种回答就不太理想。
面试复盘是我每次跳槽都会做的事。每场面试结束，趁着记忆还新鲜，把被问到的问题记下来。答得好的地方，总结一下为什么好。答得不好的地方，查资料补上。连续面几场之后，你会发现有些问题反复出现，那就是你的知识盲区。心态也很重要。面试是双向选择，面试官在挑你，你也在挑团队。遇到压力面，别慌，保持礼貌和冷静。遇到不会的问题，坦诚说“这块我了解得不够深入”，然后试着从已知的知识推导。撒谎或者硬编，面试官一眼就能看穿。我面过一个人，简历上写精通JVM调优，问他G1的回收流程，他说“就是那个分代回收”，再问详细点就支支吾吾。后来他承认只是看过几篇文章。坦诚一点，反而会给人留下好印象。面试失败不代表你不行，可能只是匹配度不够。复盘、补漏、再战，每一次面试都是一次成长。
6.1 云原生、容器化与Java应用现代化
我刚开始工作的时候，Java应用部署还是打war包扔到Tomcat里，改个配置要重启，扩容要手动装环境。后来Docker出现了，我把应用打成镜像，感觉世界变了。Kubernetes管理容器，滚动更新、自动扩缩容，这些能力让Java应用的运维方式彻底改变。云原生不只是技术，更是一种理念。Spring Boot天生适合容器化，内嵌Tomcat，打包成可执行jar，配合Dockerfile就能跑。我现在的项目基本都用K8s部署。Java应用现代化还包括GraalVM native image，启动速度快，内存占用低。只是native image对反射和动态代理支持有限，需要额外配置。我试过用Quarkus写一个服务，启动时间从几秒降到几十毫秒，挺震撼的。学习云原生，我的建议是先掌握Docker基本命令，再学K8s的核心概念Pod、Service、Deployment，之后动手把一个小项目容器化部署到Minikube上。这个过程会让你对Java应用的运行时环境有全新的认识。
很多Java开发者觉得云原生是运维的事，跟我没关系。我一开始也这么想。后来发现，不懂容器化，你连自己应用的日志都找不到。不懂K8s的探针配置，你的应用可能因为健康检查失败被反复重启。Java应用现代化还涉及配置管理、服务发现、可观测性。Spring Cloud Kubernetes、Micrometer、OpenTelemetry这些工具，都是Java开发者需要了解的。我见过一个团队，应用上了K8s却没用ConfigMap，配置还是写在镜像里，每次改配置都要重新构建镜像。这种就是没理解云原生的精髓。云原生时代，Java开发者要往前多走一步，了解基础设施，写出更适合云环境的代码。比如优雅停机、健康检查端点、指标暴露，这些在Spring Boot Actuator里都有现成支持。花点时间研究一下，面试和工作中都会加分。
6.2 大数据、人工智能与Java生态结合
大数据这块，Java一直有很强的存在感。Hadoop、Spark、Flink这些框架都是用Java或Scala写的。我做过一段时间的实时数据处理，用Flink消费Kafka，做窗口聚合，再写入ClickHouse。整个链路都是Java生态。Flink的DataStream API用起来很顺手，Java开发者转大数据开发，门槛不算高。Spark的RDD和DataFrame，Scala写起来更简洁，Java API也能用。如果你对大数据感兴趣，可以先学Hadoop的HDFS和MapReduce，理解分布式存储和计算的思想。接着上手Flink，做一个实时统计的demo。Java的并发包和JVM调优经验，在大数据场景下非常值钱。Flink任务调优，本质上就是JVM调优加算子优化。我调过一个Flink作业，频繁Full GC，后来发现是状态太大，调整了RocksDB后端和内存比例，作业就稳定了。这段经历让我明白，底层技术是相通的。
人工智能跟Java的结合，以前总觉得有点远。Python是AI的主流语言，Java好像插不上手。这两年情况变了。TensorFlow有Java API，Deeplearning4j是纯Java的深度学习库，DJL是亚马逊开源的Java深度学习框架。我试着用DJL加载了一个预训练的BERT模型，做文本分类，代码量不多，推理速度也还行。Java在AI领域的优势在于工程化。训练模型用Python，部署模型用Java，这种组合在很多公司都能看到。Java服务的高并发、稳定性、成熟的微服务生态，是AI模型落地的良好载体。我认识一个做风控的团队，模型训练用Python，线上服务用Java，通过gRPC调用模型推理。这种架构很常见。如果你想在Java里玩AI，可以从DJL或者TensorFlow Java开始，跑几个例子，理解模型加载和推理的过程。不用成为算法专家，但要知道怎么把模型集成到Java应用里。这个技能在未来的求职中会越来越吃香。
6.3 技术社区、源码阅读与个人品牌建设
我写技术博客是从三年前开始的。一开始只是记录工作中遇到的问题，比如“Spring循环依赖怎么解决”、“MySQL死锁排查过程”。写着写着，发现自己的思路更清晰了。输出是最好的学习方式，这句话我深有体会。技术社区不只有博客，还有GitHub、Stack Overflow、掘金、CSDN。我在GitHub上给几个开源项目提过PR，虽然只是改文档、修小bug，跟maintainer交流的过程让我学到很多。源码阅读也是成长的关键。我读的第一份源码是Spring的IoC容器，对着调试一步步看Bean的创建过程。后来读JDK的ConcurrentHashMap、AQS，理解并发大师的设计思路。读源码不要一开始就啃最难的，从简单的工具类开始，比如String、ArrayList，再到集合框架，再到Spring核心。我习惯用IDEA的debug功能，在关键行打上断点，观察变量变化。这样比光看代码有效得多。
个人品牌这件事，以前我觉得是网红才需要做的。后来发现，技术人的个人品牌就是你的影响力。你在社区里的发言、你写的文章、你维护的开源项目，都是你的名片。我面试的时候，面试官看到我博客里有一篇讲JVM调优的文章，就顺着问了几个问题。写过之后，答得很顺。个人品牌不是让你去炒作，而是持续分享有价值的内容。你可以从写周报开始，把每周学到的技术点整理成短文发出来。也可以在团队内部做技术分享，锻炼表达能力。时间长了，你会发现自己成了某个领域的“熟面孔”。机会也会主动找上门。我有个朋友，经常在掘金发Flink实战文章，被一家公司挖去做大数据平台。技术社区是开放的，你贡献的每一份内容，都在为你积累信用。别想着一夜爆红，细水长流就好。
6.4 职业规划：初级、中级、高级与架构师路径
我带过不少新人，也面过很多资深开发者。初级工程师的核心任务是完成任务。给你一个需求，你能照着文档和示例把代码写出来，能跑通，不出大bug，就算合格。这个阶段要打好基础，把Java语法、集合、并发、Spring Boot用熟。别急着学高大上的架构，先把CRUD写扎实。中级工程师要能独立负责模块。需求来了，你能拆解任务，设计接口，考虑异常情况，写单元测试。遇到问题能自己排查，不依赖别人。这个阶段要深入原理，知道Spring Boot自动配置怎么实现的，MySQL索引怎么优化的。高级工程师要能带小团队，做技术方案，把控项目进度。你要能预判风险，解决复杂问题，在性能和稳定性上做权衡。我见过一些高级工程师，代码写得不多，每次评审都能指出关键问题。他们的价值在于经验和判断力。
架构师是很多人的目标。架构师不只是一个title，更是一种能力。我理解的架构师，要能站在业务全局看技术，做技术选型，设计系统架构，保证高可用、高并发、可扩展。架构师要懂业务，不懂业务的架构师设计出来的系统就是空中楼阁。架构师还要有前瞻性，能判断技术趋势，比如云原生、Service Mesh、Serverless。从高级到架构师，需要刻意练习。你可以从一个小系统的架构设计开始，画部署图、时序图，做容量规划。之后参与公司级的项目，跟资深架构师学习。我自己的路径是先做业务开发，再做中间件，再做架构。每一步都补上了不同的知识。职业规划不是一成不变的，有人适合走技术专家路线，有人适合走管理路线。找到自己的兴趣和优势，比盲目追title重要。
6.5 持续学习方法与长期竞争力构建
技术更新太快了，Java 8还没用熟，Java 17、Java 21都出了。Spring Boot 2.x还没摸透，3.x已经普及。持续学习不是口号，是生存技能。我的学习方法很简单：每天花半小时看技术资讯，每周写一篇总结，每月读一本技术书或者一个开源项目的源码。碎片化学习有用，不成体系。我会定期做主题学习，比如这个月专门学K8s，下个月学Flink。主题学习要配合实践，光看文档记不住。我会在本地搭环境，跑demo，遇到问题查资料。输出倒逼输入，写博客、做分享，都是很好的方式。还有，英语能力很重要。最新的技术文档、源码注释、社区讨论都是英文的。我坚持每天读几篇英文技术文章，一开始很吃力，现在习惯了。这个习惯让我获取信息的速度快了很多。
长期竞争力不只看技术深度，还看学习能力、解决问题能力、沟通协作能力。技术会过时，学习能力不会。我见过一些老程序员，技术栈停在十年前，不是他们学不会，是不愿意学。保持好奇心，对新技术不排斥，这是基础。解决问题的能力，是在一次次踩坑中锻炼出来的。线上故障、性能瓶颈、疑难bug，解决一次，就成长一次。沟通协作也很重要。架构师要跟产品、运维、测试打交道，表达不清楚，方案再好也推不动。我刻意练习过写技术方案文档，用图表和简洁的语言把复杂问题讲清楚。长期竞争力是多个维度的组合。你不需要样样顶尖，但要有自己的长板，没有明显短板。找到自己的节奏，持续投入，时间会给你回报。
