企业官网建设流程全解析

写Java相关的知识点，其实是个挺大的筐。从集合框架、并发编程到JVM调优，随便拎出一个都能写一本书。但根据我这几年一线的开发经验，真正决定代码质量的，往往是那些底层原理和隐藏的坑。这篇内容不是我面试前的八股背诵，而是我在实际项目里反复踩过、验证过的经验沉淀。我会用最直接的方式，把高频核心知识点拆开揉碎，告诉你怎么用、为什么这么用、以及哪些地方最容易翻车。

内容适合刚入行两三年的Java开发，也适合准备系统梳理知识体系的朋友。看的时候建议配合自己的代码实践，光收藏是没有用的。

1. 集合框架的底层逻辑与选型思路

集合框架是Java日常开发中使用频率最高的一类工具，但很多人只停留在List、Map换个用的层面。底层结构不同，性能差异可能是数量级的。这一部分我把几个最核心的集合类讲透。

1.1 HashMap的底层实现、扩容机制与哈希碰撞

先说HashMap。它是Java 8之后面试和开发中永远绕不开的一个点。底层结构是数组加链表，链表长度达到阈值时转为红黑树。这个设计背后是有完整考量的。

数组的作用是通过哈希值直接定位桶位置，理想情况下时间复杂度是O(1)。但哈希函数不可能完美，不同key计算出相同下标就会发生碰撞，碰撞的元素用链表串起来。Java 8之前链表是唯一处理碰撞的手段，但如果碰撞严重，链表过长，get操作的复杂度会退化到O(n)。所以Java 8引入了红黑树，当链表长度超过8且数组容量达到64时，链表转红黑树，把最坏情况下的查找复杂度降到O(log n)。

为什么要等容量达到64才允许树化？这点容易被人忽略。如果数组容量很小，比如只有16，那么即使链表长度到了8，更合理的做法是扩容数组，让元素分散到更多桶里，而不是急着树化。容量小时，扩容的代价远低于维护红黑树的代价。红黑树本身也有开销，节点占用的内存大约是链表节点的两倍，而且旋转操作在插入删除时很频繁。所以树化是为了极端情况兜底，正常场景下链表已经够用。

扩容是HashMap的另一个关键机制。默认初始容量是16，负载因子是0.75，意思是当元素数量达到16 * 0.75 = 12个时，会触发扩容，每次扩大到原来的两倍。扩容时会重新计算所有元素的位置，这是一个相对昂贵的操作。

为什么负载因子取0.75而不是1？这是个典型的空间和时间权衡。如果负载因子设为1，意味着数组快塞满了才扩容，桶位置冲突的概率会明显上升，链表变长的可能性增大，查找效率降低。如果设为0.5，哈希冲突少，但空间浪费严重，有一半的桶是空的。0.75是大量实验和数学推导之后取的平衡值。日常开发中建议不要轻易改这个值，除非你能准确预测数据的分布。

实际项目里有两个高频坑，值得专门说一下。

第一个坑是并发环境下的使用。HashMap不是线程安全的，多个线程同时put时，可能出现数据覆盖，甚至在JDK 7及以前，扩容时头插法会形成环形链表，导致get时死循环。虽然JDK 8改成了尾插法，环形链表的问题从根源上消失了，但数据竞争依然存在，所以并发场景请用ConcurrentHashMap，不要心存侥幸。

第二个坑是key对象可变导致的查找失效。如果使用自定义对象作为key，并且这个对象的hashCode()依赖了某个可变字段，那么在放入HashMap之后修改这个字段，再次get时就会找不到对象。我遇到过一个实际案例，某开发同学用实体对象做 key，后续业务里改了实体的某个属性，缓存里的数据就再也取不出来了，排查了很久才发现是key的哈希值变了。所以用可变对象做key是典型的反面教材。正确的做法是用不可变对象，或者至少保证参与hashCode()计算的字段在生命周期内不变。

再补一个经常被问到的点：ConcurrentHashMap在JDK 8做了什么优化。JDK 7的实现是分段锁，把整个Map分成若干Segment，每个Segment是一把独立的锁，理论上并发度是Segment的数量。JDK 8放弃了分段锁，改为对桶头节点加锁，配合CAS操作，锁粒度更细，并发度更高。同时JDK 8的ConcurrentHashMap也引入了红黑树，整体结构和HashMap保持一致。实际项目里，ConcurrentHashMap的读写性能在大多数场景下都比Hashtable高一个档次，Hashtable是对整个表加锁，现在基本可以淘汰了。

1.2 ArrayList、LinkedList与扩容细节：别再凭感觉选型

List的选型是另一个高频话题。很多同学一上来就用ArrayList，理由仅仅是"大家都这么用"。这个说法不全面，但大部分时候确实是对的。问题是你得知道为什么。

ArrayList底层是Object数组，支持随机访问，get操作的时间复杂度是O(1)。缺点是插入和删除操作，如果是中间位置，需要移动后续所有元素，时间复杂度是O(n)。LinkedList底层是双向链表，插入和删除只需要修改指针，理论上是O(1)，但前提是你已经定位到了那个节点。LinkedList的get操作需要从头部或尾部遍历，复杂度是O(n)。

实际业务里，遍历读取、按索引取值这些操作远多于在中间插入删除。所以ArrayList更常用不是没有道理。但如果你需要频繁在头部插入元素，比如实现一个队列或者一个操作日志列表，LinkedList会更合适。当然更专业的做法是用ArrayDeque，它在头部尾部的操作上都比LinkedList高效，而且内部是循环数组，内存也更紧凑。

还有个细节是ArrayList的扩容机制。默认容量是10，每次扩容为原来的1.5倍。为什么是1.5倍？因为扩容时要申请新数组，然后把旧数组的元素复制过去，这是O(n)的操作，扩容次数越少越好。1.5倍是综合考虑空间浪费和扩容次数的结果。2倍虽然扩容次数更少，但空间浪费更大；1.5倍是Java开发团队权衡后的选择。如果你能预估数据量，建议在构造时直接指定初始容量，比如new ArrayList<>(expectedSize)，能减少无谓的扩容复制。

再列举几个平时容易踩的小细节：

• Arrays.asList()返回的是一个定长的内部List，不能调用add和remove，否则会抛UnsupportedOperationException。而且它是对原数组的视图，修改这个List会同步修改原数组。
• Arrays.asList()如果传入的是基本类型数组，比如int[]，得到的是List<int[]>，不是List<Integer>。因为泛型不支持基本类型，整个数组会被当成一个元素。要转成List<Integer>需要自己循环装箱。
• subList()返回的是原List的视图，对subList的修改会反映到原List上。如果subList持有期间原List被结构性修改，再操作subList会抛ConcurrentModificationException。

2. 并发编程：同步机制与线程池实战

并发编程是Java进阶的必经之路，也是线上问题的高发区。很多人程序单线程跑得好好的，一上多线程就出各种诡异问题。这背后是JMM（Java内存模型）、指令重排序、原子性、可见性这些底层概念在起作用。

2.1 volatile与synchronized：从JMM可见性到锁升级

先理解一个核心概念：Java线程共享主内存，但每个线程还有自己的工作内存。线程对变量的操作是在工作内存中进行的，操作完成后再同步回主内存。如果多个线程同时操作一个变量，可能会读到过期的值，这就是可见性问题。

volatile关键字的作用是保证可见性并禁止指令重排序。具体来说，一个volatile变量的写操作会立即刷新到主内存，读操作会从主内存读取，而不是从工作内存的缓存读取。这保证了多个线程看到的总是最新值。

但volatile有一个非常重要的限制：它不能保证原子性。经典的例子就是i++。这个操作本质上包含三步：读取i的值、计算i+1、把新值写回。volatile只能保证三步各自的内存可见性，但三步之间有窗口期，多个线程可能同时读到旧值，都会写回一个相同的值，导致计数结果偏小。所以volatile适合的状态标志位，比如线程的开关标志、初始化的发布标志，不适合做计数器。

synchronized是Java内置的互斥锁，它提供的是排他性，同一时刻只有一个线程能进入临界区。和volatile不同，synchronized既保证了可见性，也保证了原子性。

JDK 6之后，synchronized经历了锁升级的优化过程。锁的状态从无锁、偏向锁、轻量级锁到重量级锁。偏向锁的思路是：如果一个锁被同一个线程反复获取，那就没必要每次都做CAS操作，直接记录线程ID，下次进来判断一下是不是同一个线程就行。锁升级的触发条件是竞争。当有另一个线程来竞争时，偏向锁撤销，升级为轻量级锁。轻量级锁通过自旋等待锁释放，适合锁持有时间很短的场景。如果自旋一段时间后仍然获取不到锁，就升级为重量级锁，此时线程会进入阻塞状态，需要操作系统调度，开销最大。

理解这个机制对实际调优很有帮助。如果你的临界区代码执行时间很短，比如只有几次变量赋值，轻量级锁和自旋会表现得很好。但如果临界区里面有网络IO、数据库查询这类耗时操作，线程长时间持锁，自旋就是浪费CPU，这时候直接走重量级锁反而更合理。

实际开发中，我建议优先使用synchronized，因为它简单可靠，顺手就能写对。ReentrantLock的优势在于更灵活的锁获取方式、超时控制、公平锁设置，以及可以绑定多个Condition条件队列。如果你只是简单的互斥需求，用synchronized就足够了。

一个典型场景是单例模式中的双重检查锁定（DCL）。代码长这样：

public class Singleton { private static volatile Singleton instance; private Singleton() {} public static Singleton getInstance() { if (instance == null) { // 第一次检查 synchronized (Singleton.class) { if (instance == null) { // 第二次检查 instance = new Singleton(); } } } return instance; } }

这里volatile是必须的，原因在于new Singleton()不是原子操作，它大致分三步：分配内存、调用构造器初始化对象、把引用指向这块内存。如果不加volatile，指令重排序可能导致第二步和第三步顺序颠倒。极端情况下，线程A先给instance赋了引用，但对象还没初始化完成，线程B进来看到instance不为null，直接return了一个半初始化的对象，程序就出问题了。volatile禁止了这三步的重排序，保证安全。

还有一个特别容易被忽略的坑：synchronized锁的对象不能是包装类或字符串常量。我曾经接过一个case，代码里用synchronized (someInteger)做并发控制，一开始没问题，后来有人不小心改了someInteger的值，就立刻锁不住了。原因就是包装类对象的引用变了，锁的对象根本不是同一个。字符串锁也有同样的问题，如果字符串值相同，它们在常量池中可能是同一个对象，两个不相关的并发操作可能互相阻塞；如果值不同，又是另一把锁，完全控制不住。最稳妥的做法是定义专门的private final Object lock = new Object()，用这个专用锁对象。

2.2 线程池核心参数、任务提交流程与拒绝策略

线程池是并发编程中最常用的工具之一。但很多开发者对线程池的理解停留在Executors.newFixedThreadPool()这一步。这个方法是能跑，但在生产环境里，由它引发的故障我见过不止一次。

先看ThreadPoolExecutor的核心参数，一共七个：

• corePoolSize：核心线程数。即使线程空闲，也保持存活。
• maximumPoolSize：最大线程数，线程数上限。
• keepAliveTime：非核心线程的空闲存活时间。
• workQueue：任务队列，保存等待执行的任务。
• threadFactory：线程工厂，可以用来给线程命名。
• handler：拒绝策略。
• unit：keepAliveTime的时间单位。

任务的提交流程是这样的：提交一个任务时，如果当前线程数小于corePoolSize，则创建新线程执行任务；如果线程数已经达到corePoolSize，任务会放入workQueue排队；如果队列也满了，再创建新线程，直到线程数达到maximumPoolSize；如果线程数已经达到上限，队列也是满的，就触发拒绝策略。

这个流程里，很多人的误区是"队列满了才开始创建新线程"。实际上，队列满之前，核心线程之外的线程是不创建的。这就意味着：如果你用了一个非常大的无界队列，那么核心线程数之外的线程永远没有机会创建，任务全部堆积在队列里，系统的实时处理能力实际上是被核心线程数限制的。

核心线程数怎么设置？没有统一的答案，但要分场景估算。CPU密集型任务，核心线程数可以设为CPU核数加1，目的是让每个线程都能分配到独立的CPU核心，加1是为了防止某些线程因为页面故障等原因挂起时，多出来的线程能顶上去。IO密集型任务，比如文件读写、网络请求、数据库操作，重点是让线程在IO等待期间不占着CPU，核心线程数可以设得大一些，参考公式是CPU核数 * 2，或者更精细的CPU核数 / (1 - 阻塞系数)，阻塞系数一般在0.8到0.9之间。实际项目里，这个值最终还是需要靠压测和实际运行数据来调整，没有银弹。

再讲拒绝策略。ThreadPoolExecutor内置了四种策略：

• AbortPolicy：直接抛异常，这是默认策略。对重要任务来说，宁可抛异常也不能静默丢失。
• CallerRunsPolicy：任务不丢弃，而是由提交任务的线程自己执行。这个策略能天然降低提交速率，起到背压效果，适合不想丢任务但可以限速的场景。
• DiscardPolicy：直接丢弃任务，不抛异常。适合一些允许丢的辅助任务，比如日志上报。
• DiscardOldestPolicy：丢弃队列中最老的任务，然后重新尝试提交当前任务。适合追求最新数据的场景，比如新闻刷新。

真实项目里，我强烈不建议直接使用Executors的快捷方法。newFixedThreadPool使用无界的LinkedBlockingQueue，任务队列理论上可以无限堆积，内存迟早被撑爆。newCachedThreadPool的最大线程数是Integer.MAX_VALUE，如果任务提交速度快，线程数会无限膨胀，直接OOM。正确做法是手动创建ThreadPoolExecutor，使用有界队列，并自定义拒绝策略和线程名：

ThreadPoolExecutor executor = new ThreadPoolExecutor( 4, 8, 60L, TimeUnit.SECONDS, new ArrayBlockingQueue<>(100), new ThreadFactory() { private final AtomicInteger counter = new AtomicInteger(); @Override public Thread newThread(Runnable r) { return new Thread(r, "biz-thread-" + counter.getAndIncrement()); } }, new ThreadPoolExecutor.CallerRunsPolicy() );

线程命名这个看似不起眼的习惯，在线上排查问题时价值巨大。用jstack打印线程栈时，能看到"biz-thread-1"这样的名字，你立刻知道是哪个业务线程卡住了；如果所有线程都叫"pool-1-thread-1"，你只能一个个对照代码去猜。

还有一个细节，线程池中的核心线程默认不超时回收，但allowCoreThreadTimeOut(true)可以把核心线程也纳入超时管理，这对于峰谷明显的业务是个不错的选择，平时没有流量时能释放线程资源。

3. JVM内存与性能问题排查基本功

JVM调优和线上问题排查，是Java开发者从"会写代码"进阶到"能治线上病"的关键一步。很多人一听到JVM就头大，其实拆开来看，每个问题的排查思路都是固定的。这一部分我把运行时数据区基础和OOM排查流程讲清楚。

3.1 运行时数据区划分：堆、栈、方法区与元空间

JVM运行时数据区可以分成五块：堆、虚拟机栈、本地方法栈、方法区（JDK 8之后是元空间）、程序计数器。

堆是最大的一块内存区域，也是GC（垃圾回收）的主战场。它分成新生代和老年代。新生代又分成Eden区、Survivor From（S0）和Survivor To（S1），默认比例是8:1:1。新创建的对象优先分配在Eden区，Eden区满了触发Minor GC，存活的对象按年龄被挪到Survivor区，每经过一次GC年龄加1，达到阈值（默认15）就晋升到老年代。

为什么Survivor要有两块？这是为了避免碎片化。对象在S0和S1之间反复复制，每一次都保证有一块空闲区域用于容纳存活对象，这样就不用做压缩整理。如果只有一块Survivor，存活对象和垃圾对象会混在一起，后续分配就没有连续空间了。为什么Eden区这么大？因为大多数对象都是"朝生夕死"的，绝大部分在第一次Minor GC时就会被回收，Eden区越大，Minor GC的触发频率就越低。

虚拟机栈和堆正好相反，它不涉及GC，但它的容量限制会导致StackOverflowError。每个线程创建一个栈，每个方法调用对应一个栈帧，栈帧里保存局部变量表、操作数栈、动态链接和方法出口。递归调用过深或者循环调用没有出口，就会把栈内存耗尽，抛出StackOverflowError。这个错误不是内存不足，而是线程栈的深度超过了限制，可以通过-Xss参数调整栈大小，但一般不建议随意调大，因为每一个线程都会占一块栈内存，线程数越多，总占用量越可观。

方法区在JDK 8之前叫永久代，存放类元数据、常量池等。JDK 8之后改名为元空间，并且移到了本地内存，也就是说元空间的默认上限不再受JVM堆大小限制，而是受系统物理内存限制。这一改动避免了永久代内存溢出的经典问题，但也带来一个新风险：如果加载的类太多，比如多次热部署classloader没有回收，元空间会被慢慢撑爆，抛出Metaspace内存溢出。

几个关键参数整理如下：

生产环境里，-Xms和-Xmx设置相同值是对的，这样避免了堆大小在运行时反复伸缩带来的性能损耗。JVM在堆伸缩时需要执行GC，这是一个隐形的性能杀手。

3.2 线上OOM与Full GC排查思路

线上出现内存问题，最常见的有四种OOM类型，对应的处理思路完全不同。

第一种是java.lang.OutOfMemoryError: Java heap space，堆内存不足。可能的原因有：对象创建过于频繁、大对象太多、内存泄漏（对象无法被回收）。排查的第一步是用jmap -heap <pid>看当前堆的使用情况，再用jmap -dump:format=b,file=heap.bin <pid>导出堆快照，然后用MAT（Memory Analyzer Tool）分析。MAT里重点看两点：一是Leak Suspects报告，它能找到占用内存最大的对象以及GC root的引用链；二是Dominator Tree，看哪些对象真正占据了大量内存。如果发现大量某个业务对象堆积，去查它们的引用来源，基本能定位问题。

第二种是java.lang.OutOfMemoryError: Metaspace，元空间不足。这种问题常见于热部署场景、动态生成代理类、反射频繁加载类。排查思路是看jstat -gc <pid>里的Metaspace区域，以及通过-XX:MaxMetaspaceSize来约束上限。如果确认是动态生成类导致，需要检查生成类的代码逻辑，看看有没有重复生成。

第三种是java.lang.OutOfMemoryError: Unable to create new native thread，无法创建本地线程。这种问题往往不是堆内存的问题，而是操作系统线程数达到限制，或者进程虚拟内存耗尽。处理方向是排查线程数是否有异常增长，查看ulimit -u和/proc/sys/kernel/threads-max的限制。线程属于系统资源，代码里反复创建线程、线程池未复用、或者死循环疯狂新建线程都会导致这类问题。

第四种是java.lang.OutOfMemoryError: GC overhead limit exceeded。GC回收效率极低，连续回收却回收不了多少内存，JVM为了防止CPU被GC完全耗尽而主动抛出。这种情况通常是堆太小或者存在严重的短生命周期大对象问题，导致GC一直忙碌。

Full GC频繁是另一个高频痛点。排查时我习惯的顺序是：

1. 先用jps -l找到进程ID。
2. 用jstat -gcutil <pid> 1000每秒刷一次，观察Eden、Survivor、Old区的占用和GC次数。如果Old区持续增长，说明存在大量晋升对象，可能有大对象或者泄漏。
3. 用jstack <pid>查看线程状态，排查是否存在线程死锁或者长时间阻塞。
4. 如果怀疑代码逻辑有问题，用jmap -dump:live,format=b,file=heap.bin <pid>导出存活对象快照。这里live参数很重要，它会先触发一次Full GC再dump，导出的是存活对象，分析时干扰更少。

这里有个实际案例。我之前接手过一个定时任务服务，每隔一段时间Old区就涨到90%以上，Full GC一次能回收一部分，但很快又涨回来。排查代码发现，有个批量处理逻辑每次都把全量数据加载进内存，生成了一大批临时对象。虽然这些对象很快就不再被引用，但在量大的时候，大对象直接晋升到老年代，老年代空间不够了就只能频繁Full GC。这个问题的处理方式是对批量逻辑进行分页，每次只处理一小批数据，避免一次性创建大量临时对象。

再说一个很实用的排查工具思路：Arthas。它是阿里开源的Java诊断工具，可以不重启服务进行在线诊断。我常用的命令有dashboard看整体运行状态，thread查线程堆栈，jvm看JVM内存和GC情况，stack定位方法调用路径，watch观察方法入参和返回值。这些功能对于线上问题的即时诊断帮助极大，尤其是那些不能随意重启的服务。

4. 异常处理与日志规范：让代码更健壮

异常处理和日志规范，是最能体现工程水平的地方。功能实现得好不好，看的是代码逻辑；系统稳不稳定，很大程度上看的是异常处理做得细不细。这一部分聊聊怎么写出既健壮又容易排查的代码。

4.1 受检异常与非受检异常的使用边界

Java把异常分成受检异常（Checked Exception）和非受检异常（RuntimeException）。受检异常要求方法必须显式声明或者捕获，比如IOException、SQLException。非受检异常不需要强制处理，比如NullPointerException、IllegalArgumentException。

这两类异常的设计意图是不同的。受检异常强调的是"异常情况必须被调用方感知并处理"，比如文件找不到、网络连接失败，这类外部因素导致的错误，调用方确实需要决策如何应对。而非受检异常通常表示编程错误或者不可恢复的异常状态，比如传参不对、空指针。

但实际开发里，我不建议滥用受检异常。一个很常见的问题是，很多框架和代码把业务校验失败也定义成受检异常，导致所有调用方都被迫处理，finally里还可能漏处理，最终异常被吞掉。理想的做法是：业务规则校验失败，直接用IllegalArgumentException或者自定义RuntimeException；外部资源错误，用受检异常并正确处理。

还有一个非常经典的错误模式：用异常控制程序流程。有些同学会在代码里循环调用一个可能会抛异常的方法，用捕获异常来判断是否继续，比如拿异常当"找不到数据"的标记。这个做法在功能上可行，但性能很差，因为异常对象的创建要填充堆栈信息，代价远高于一次普通的null判断。而且语义上也容易混淆，让读代码的人不清楚到底哪些是预期行为，哪些是真正的错误。

吞异常是更要命的问题。我见过大量这样的代码：

try { // something } catch (Exception e) { // do nothing }

这种写法等于给系统埋雷。异常被吞掉之后，日志里什么都不会留下，线上出了问题只能干瞪眼。哪怕你暂时还没想好如何处理，至少也要用log.error("xxx failed", e)把异常记录下来。

还有一个和finally相关的常见反模式：在finally里return。如果try块里有一条return语句，finally里的return会覆盖它，导致返回值不是方法逻辑里预期的值。而且finally里return会让异常被静默吞掉，因为try块的异常还没来得及传播，finally就已经return了。正确的做法是finally只做资源清理，不要写return。

自定义异常也是一个可以展开的话题。我建议自定义异常继承RuntimeException，而不是Exception，原因很简单：受检异常会让调用方被迫写大量try-catch，代码冗余且容易出错。自定义异常至少要包含错误码和业务上下文信息，这样在日志中能快速定位。

异常链的信息保留也是一个关键点。在catch中包装异常时，如果处理不当，堆栈信息会被截断。正确的写法是：

throw new BizException("something failed", cause);

一定要把原始异常对象cause传进去。如果写成new BizException(e.getMessage())，堆栈信息就丢了，线上排查时你只能看到异常被包装处的栈，看不到真正的根因在哪。

在Java 7之后的try-with-resources是一种更优雅的资源关闭方式。只要实现了AutoCloseable接口，比如FileInputStream、Connection，都可以写在try括号里，程序结束时会自动调用close。这样既避免了finally里写关闭代码，也避免了关闭代码本身可能抛出的异常覆盖原来的异常。

4.2 日志分级、关键埋点与可观测性

日志是程序在运行时的唯一"眼睛"。遇到线上问题，第一个想到的往往就是看日志。但日志打得不好，看得越多越糊涂。

日志级别从低到高分为TRACE、DEBUG、INFO、WARN、ERROR。分级的核心原则是：不同环境的关注点不同，日志要按需选择级别。开发环境可以开DEBUG，生产环境建议至少INFO起。业务的关键步骤、主要流程节点，用INFO记录状态变化；潜在风险但不影响主流程的，用WARN；发生了异常或者纠错逻辑被触发，用ERROR。DEBUG不要乱打，生产环境除非临时排查问题，否则不要开，因为日志本身就是性能杀手。

日志输出有一个高频错误：只打异常消息，不打堆栈。典型的错误写法是：

log.error("operation failed: {}", e.getMessage());

这样做的问题在于，你只看到了异常的描述信息，不知道异常是从哪里抛出来的，调用链是什么。正确的姿势是：

log.error("operation failed", e);

第二个参数直接传异常对象，日志框架会自动打印完整的堆栈。这在排查时能省下大量时间。

日志还有一个和性能相关的细节：字符串拼接。log.info("user id: " + userId + ", order id: " + orderId)这种写法的问题在于，如果当前日志级别是WARN，INFO日志根本不会输出，但字符串拼接的耗时已经发生了。正确的做法是用参数化占位符：

log.info("user id: {}, order id: {}", userId, orderId);

这样做的好处是，日志框架会先判断当前级别是否需要输出，需要时才进行字符串格式化，性能更好。

可观测性方面，推荐使用MDC（Mapped Diagnostic Context）来关联traceId。做法是在请求入口处生成一个唯一的traceId，写入MDC，然后在日志配置里加上%X{traceId}占位符。这样一条请求链路里所有的日志都会带上同一个traceId，排查问题时，用traceId一搜，整条调用链就串起来了。

我参与过的项目中，日志规范一般会包含这么几条硬性要求：

• 日志必须包含时间戳、线程名、traceId、logger名称、日志级别、消息内容。
• 业务异常必须记录完整的异常对象和业务上下文。
• 不允许使用System.out.println输出日志，必须是统一的日志框架。
• 用户隐私信息不允许打印，比如密码、手机号、身份证号，必要时脱敏。
• 不允许在循环体内打印DEBUG及以上级别的日志，防止大量日志刷屏。

最后再提一个实际的应用场景：日志不光是为了排错，还是做性能观察的重要数据源。比如某个服务的RT变长，你翻日志发现数据库查询耗时占了大头，再配合慢SQL分析，很快就能定位到问题。所以每一条日志背后，都对应着一个可观测的信号，想清楚这条日志将来要回答什么问题，再决定要不要打、用什么级别打。

跟着这条思路走下来，你会发现Java的知识点其实是体系化的。最开始你可能只能记结论，比如HashMap为什么是1.5倍扩容、负载因子为什么是0.75、DCL为什么要加volatile，但真正把原理串起来之后，这些就不再是需要死记的答案，而是自然推导的结果。我个人在实际操作中最大的体会是：任何知识点都要落到线上场景去验证。比如你理解了线程池的拒绝策略，就会在业务高峰期主动观察任务队列的积压情况；你理解了GC机制，就会去关注Full GC的频率而不是只看CPU。这个从"知道"到"做到"的过程，就是经验和能力的积累。