企业官网建设流程全解析

我前阵子帮一个团队复盘AI应用开发的项目，代码走查时发现好几个地方都在做字符串拼接。有直接写String result = ""然后循环append的，有在接口日志里用加号拼参数值的，还有处理大模型返回的JSON时反复切割字符串的。其实这些写法在本地上线没问题，一旦请求量上来或者数据量变大，性能和内存占用立刻露馅。这篇东西就想把这些Java API的老底儿翻一翻——String、StringBuilder、StringBuffer和ArrayList到底该怎么用，尤其是在AI应用开发那种高并发、大数据量场景下，这几个类的选型差一点，整个服务的表现就差一大截。

这篇内容适合三类人看：刚学Java准备面试的，写业务代码但对性能不敏感的，以及在AI应用里做接口封装、数据处理模块的开发者。文章不会讲太多底层源码，但会把每个关键机制背后的原因讲透，并直接给出可以照抄的写法。整理完之后你会发现，绝大多数线上问题其实都是基础API的使用姿势不对导致的，改起来不难，难的是意识到哪里出了问题。

1. 内容整体设计与思路拆解

1.1 为什么AI应用开发绕不开这四个类

很多人觉得AI应用开发的难点在算法、模型、Prompt设计，基础API有什么好讲的。但真正上手写过一个对接大模型的服务就会发现，代码里跑得最频繁的恰恰是字符串处理和集合操作。大模型API的请求报文要拼接，返回的JSON要解析，上下文要缓存，多轮对话的历史记录要存，这些全是String和ArrayList的活。

举个例子，一个简单的对话服务，用户发一句话，你要拼系统提示词、拼历史对话、拼用户消息，这中间至少产生十几处字符串操作。如果都用String直接拼接，每次都会生成新的字符串对象，内存分配次数急剧增加，GC压力变大。在高并发场景下，这种看似不起眼的写法会让服务吞吐量肉眼可见地下降。

1.2 从业务场景反推技术选型

我在设计代码结构时习惯先列场景，再定技术方案。对接大模型API这个场景里，有这么几个典型需求：

• 拼接请求体：通常用JSON格式，需要把用户输入和历史消息组织成一个结构化的字符串。
• 记录调用日志：每条请求要记录入参、出参、耗时，这些内容在日志框架里往往是字符串拼接完成的。
• 缓存和解析：模型返回的内容可能要经过切割、替换、提取关键词等操作，这需要对字符串做频繁修改。
• 维护会话上下文：多轮对话里的历史消息要按顺序存储、追加和删除，这天然适合ArrayList。

需求定下来之后，选型逻辑就很清晰了。需要频繁拼接的场景，用StringBuilder；需要线程安全且操作频繁的场景，考虑StringBuffer或加锁的StringBuilder；需要存储动态长度数据的场景，用ArrayList。而String更像是“数据载体”，负责承载不可变的内容，比如配置常量、用户输入、模型返回的最终结果。

1.3 这套方案的优势和避开的坑

这套思路最大的好处是把“可变”和“不可变”的边界划清楚了。String是不可变的，天然适合做安全的共享数据；StringBuilder是可变的，适合单线程环境下频繁修改；StringBuffer在StringBuilder基础上加了同步，适合多线程共享场景，但代价是性能下降。

很多新手容易踩的坑恰恰是边界混乱。比如在循环里用String做累加，相当于每次循环都创建一个新对象，老对象等待GC回收，循环次数多了GC就会频繁触发。另一个典型坑是ArrayList在遍历时直接删除元素，会抛ConcurrentModificationException，这个后面会详细讲。

2. String的不可变性：为什么它能当“传家宝”

2.1 不可变性的底层设计

String在Java里是被final修饰的类，内部用一个private final char[]（JDK 9以后是byte[]）来存字符。final保证了类不能被继承，数组引用不能被重新赋值，这样设计的目的很纯粹：安全性和效率。

安全性体现在多个方面。作为HashMap的key时，如果String是可变的，哈希值就可能在存储后发生变化，导致无法再通过原key找到对应值。作为文件路径、数据库连接URL、网络地址等敏感配置时，不可变性保证了它在传递过程中不能被篡改。多线程下String可以被安全地共享，不需要任何同步机制，因为它压根不会变。

效率上，字符串常量池是最大的受益者。JVM里有一个字符串常量池，直接写"hello"这种字面量时，会先去池里查有没有相同内容，有就直接复用引用。这样大量相同的常量字符串只会存一份，节省内存。

2.2 equals和==的天壤之别

这是面试里被问烂了的问题，但我发现实际工作中还有很多人搞混。==比较的是引用地址，equals比较的是内容。看这段代码：

String a = "hello"; String b = "hello"; String c = new String("hello"); System.out.println(a == b); // true，两个字面量指向常量池同一个对象 System.out.println(a == c); // false，new出来的在堆上，引用不同 System.out.println(a.equals(c)); // true，内容相同

为什么a == b是true？因为两个字面量都在常量池里找内容，找到了就返回同一个引用。而new String("hello")强制在堆上创建了一个新对象，引用自然不同。理解了这一点，就能明白为什么业务代码里判断字符串相等必须用equals，绝不能用==。

还有一个隐藏的坑是equals和equalsIgnoreCase。处理用户输入时经常要比较关键词，比如判断用户是否触发了退出指令，用equalsIgnoreCase可以避免大小写问题。

2.3 不可变性带来的“隐形性能陷阱”

不可变性是好设计，但它有个副作用。任何对字符串内容的修改——拼接、切割、替换——都会产生新的String对象。写这样的代码：

String result = ""; for (int i = 0; i < 1000; i++) { result += i; }

每一次+=都等价于result = result + i，JVM先创建一个StringBuilder，调用append，再toString生成一个新String。循环1000次就创建了1000个中间对象。这个操作在数据量小的时候看不出问题，但到了十万级、百万级拼接时，内存分配和GC就成了灾难。

实际操作中，我处理大模型返回的流式内容时遇到过这种情况。模型输出是按token分批返回的，如果每批都用String +=累加，几万token下来性能就很差了。正确的做法是用StringBuilder的append方法一路追加，最后一次性toString。

2.4 intern方法：慎用但得会用

String.intern()是一个比较冷门的方法，它的作用是把字符串内容放到常量池里，并返回池中的引用。如果你有一批内容相同但通过new String创建的对象，调用intern后可以统一引用，节省内存。

但我要说，这个办法在现代JDK里并不推荐滥用。intern的实现依赖于常量池，池本身是存在堆里的（JDK 7以后从方法区移到了堆），如果放入过多字符串，反而增加内存压力。只有当你能确认字符串内容重复率高、且数量巨大时，才值得考虑。

3. StringBuilder和StringBuffer：可变字符串的正确玩法

3.1 为什么Java要提供两个可变字符串

StringBuilder和StringBuffer的API几乎一样，核心方法都是append、insert、delete、reverse、toString，区别在于StringBuffer的方法加了synchronized关键字。这个差异在单线程环境里完全体现不出来，但在多线程环境下决定了安全性。

我个人的选型原则是：没有明确的多线程共享需求，一律用StringBuilder。Java官方文档对StringBuffer的说明也提到，如果不需要线程安全，优先使用StringBuilder，因为它更快。

有一个容易忽略的点是，StringBuilder和StringBuffer只保证单个方法调用的原子性。比如两个线程同时对同一个StringBuffer调用append，能保证不会写乱，但如果你在一个线程里先append再insert，另一个线程的append可能穿插在中间，整个内容顺序还是乱。所以“线程安全”不等于“业务安全”，多线程下的操作序列仍然需要外部同步。

3.2 初始容量到底该不该设

StringBuilder内部用char数组存字符。没指定容量时默认是16，append的内容超过数组长度时触发扩容。扩容不是简单的翻倍，代码里是(oldCapacity << 1) + 2，也就是大约两倍再加2。扩容需要创建新数组、拷贝旧内容，这是O(n)的操作。

我们可以通过构造器直接指定容量：

// 预估会拼出1000字符，直接指定容量，避免中间扩容 StringBuilder sb = new StringBuilder(1000);

这个设定在高频拼接场景下收益明显。比如拼一条上万字符的调用日志，如果默认16起步，中间要扩容十几次，创建十几个临时数组。如果一开始就给了预估容量，整个过程零扩容。

估容量的原则是“宁多勿少”。多分配一些只浪费少量内存，但少分配会导致多次扩容，性能损失更大。有一种常见做法是让ArrayList或StringBuilder的初始容量比预估值略大20%左右，给波动留余量。

3.3 循环里拼接字符串的正确姿势

说一下循环内拼接的标准写法，这个在代码review里是重灾区。

错误写法一：用String拼接。

String result = ""; for (String item : items) { result += item + ","; }

这个前面说过，每次循环产生两到三个临时对象，性能最差。

错误写法二：把StringBuilder创建在循环内部。

for (String item : items) { StringBuilder sb = new StringBuilder(); sb.append(result).append(item); result = sb.toString(); }

这个相当于每次循环都new一个StringBuilder，虽然比直接加号好一点点，但仍然是不必要的对象创建。

正确写法是循环外创建StringBuilder，循环内只append，最后toString：

StringBuilder sb = new StringBuilder(items.size() * 20); for (String item : items) { sb.append(item).append(","); } String result = sb.toString();

给StringBuilder指定一个基于预估量的容量，循环内零扩容、零新对象，这是性能最优的写法。

3.4 为什么chat场景下StringBuilder是主力

回到AI应用场景。对接大模型API时，请求体的构建、响应流的累积、历史记录的拼接，全是StringBuilder的活。

我用一个实际例子说明。假设要调一个大模型接口，请求体是JSON格式：

{ "model": "gpt-xxx", "messages": [ {"role": "system", "content": "你是一个助手"}, {"role": "user", "content": "你好"} ], "temperature": 0.7 }

代码里可以这样拼：

StringBuilder body = new StringBuilder(512); body.append("{\"model\":\"gpt-xxx\",\"messages\":["); body.append("{\"role\":\"system\",\"content\":\"").append(systemPrompt).append("\"},"); body.append("{\"role\":\"user\",\"content\":\"").append(userInput).append("\"}"); body.append("],\"temperature\":0.7}"); // HTTP客户端里设置请求体

这种写法比用String.format或JSON库序列化更轻量，性能更好。当然如果结构复杂，用Jackson或Gson更稳妥，但对简单结构来说，StringBuilder拼JSON是最高效的做法。

3.5 大量文本处理时StringBuilder的进阶用法

除了append，StringBuilder还有几个实用方法值得掌握。insert(int offset, String str)可以在指定位置插入内容，比如在长文本的中间插入一段标识。delete(int start, int end)可以删除指定区间，reverse()可以直接反转字符串。

这些方法都直接在原数组上操作，不产生新对象。但注意，这些方法在底层也会触发数组拷贝，频繁在头部insert会导致整体shift，性能接近O(n)。如果有频繁头部插入的需求，考虑用LinkedList或Deque来替代，或者先在尾部构建再整体反转。

4. ArrayList的扩容机制和工程实践

4.1 ArrayList不是“数组列表”那么简单

ArrayList的底层实现是Object数组，但它封装了动态扩容能力。用户不需要关心数组长度变化，add时如果容量不够，内部自动扩容。

JDK 8的ArrayList默认容量是10，但注意是懒加载。新建ArrayList时底层其实是空数组，第一次add时才扩容到默认容量10。JDK 7及之前是构造时就分配10的容量，这个区别在面试时能答出来很加分。

扩容公式是newCapacity = oldCapacity + (oldCapacity >> 1)，也就是1.5倍。比如容量10扩容到15，15扩容到22。扩容会创建一个新数组，调用Arrays.copyOf把旧内容拷过去。频繁扩容会导致频繁数组复制，所以如果能预判元素数量，应该在构造时指定初始容量。

// 预判会有10000条会话记录，直接指定容量 List<String> history = new ArrayList<>(10000);

4.2 add、remove的时间复杂度真相

ArrayList最擅长的是按索引随机访问，时间复杂度O(1)。但add(E e)在尾部追加时，如果不需要扩容也是O(1)，需要扩容时是O(n)。add(int index, E element)在指定位置插入，需要把后面的元素全部往后移一位，时间复杂度O(n)。

remove(int index)同理，删除中间元素会把后面的元素全部往前移，O(n)。remove(Object o)还要先做线性搜索找到位置，再移动，最坏情况是O(n)。

这意味着什么？如果你需要在列表头部频繁插入或删除，用ArrayList会导致大量元素搬移。这种场景应该用LinkedList，虽然它的随机访问是O(n)，但头部插入是O(1)。

AI应用里有个典型场景：维护一个最多N条消息的滑动窗口。每次新增消息时删除最旧的一条，即list.remove(0)。用ArrayList做这个操作，每次要搬移所有剩余元素，窗口越大性能越差。用LinkedList的addFirst和removeLast则高效得多。实现一个简单的循环缓冲区还可以考虑ArrayDeque。

4.3 遍历时删除元素的正确姿势

这是ArrayList最经典的一个坑，直接上代码：

List<String> list = new ArrayList<>(Arrays.asList("a", "b", "c")); for (String item : list) { if ("a".equals(item)) { list.remove(item); // 这里出问题 } }

运行会抛ConcurrentModificationException，原因是foreach实际上用的是迭代器，迭代器在创建时会记录modCount（修改次数），每次调用next时检查当前modCount和预期值是否一致，不一致就抛异常。ArrayList的remove会改变modCount，所以迭代器认为“列表被第三方修改了”，直接报错。

三种正确的删除方式：

第一种，用迭代器自带的remove方法。

Iterator<String> it = list.iterator(); while (it.hasNext()) { String item = it.next(); if ("a".equals(item)) { it.remove(); } }

这种能工作是因为it.remove()会同步更新迭代器的expectedModCount。

第二种，从后往前遍历，用普通for循环和list.size()。

for (int i = list.size() - 1; i >= 0; i--) { if ("a".equals(list.get(i))) { list.remove(i); } }

倒序删除不需要担心索引位移问题，因为删除后面的元素不影响前面还没遍历到的索引。

第三种，更推荐的工程做法是使用removeIf方法，这是JDK 8引入的。

list.removeIf(item -> "a".equals(item));

一行代码搞定，底层也是迭代器实现，但封装好了，不容易出错。

4.4 ArrayList和LinkedList的选型对照

面试常问ArrayList和LinkedList的区别，我在这里给一个实操层面的对照：

工程上90%的列表场景用ArrayList就够了。LinkedList的内存开销大、缓存命中率低，实际性能往往没有理论值好看。除非你的核心操作确实是头部插入删除，否则别用LinkedList替代ArrayList。

4.5 ArrayList的线程安全问题

ArrayList不是线程安全的。多线程同时add，会出现覆盖丢失、数据错乱等问题。网上流传的解决方案有三个：

Vector是老牌线程安全List，方法加了synchronized，但性能和扩展性都不好，现在基本不推荐新代码使用。

Collections.synchronizedList(new ArrayList<>())是包装器方案，把每个方法加锁，但整体复合操作（比如先判断再添加）仍需手动同步。

CopyOnWriteArrayList是并发包里的方案，写操作时复制整个底层数组，读操作无锁。它适合读多写少的场景，比如配置信息、黑名单列表。但如果写操作频繁，每次复制数组的性能开销会非常大，不适合作为通用并发List。

在AI应用里，如果多个线程同时往一个List里追加模型输出的一部分，用CopyOnWriteArrayList就很不合适，因为每个thread的输出片段都会触发一次数组复制，代价太离谱。这时候更好的选择是每个线程用自己的StringBuilder，最后汇总，或者用并发队列（如ConcurrentLinkedQueue）来收集，最后再转成List。

5. AI应用开发中的实战封装与代码示例

5.1 基于StringBuilder的请求体构建器

在实际的AI应用项目中，我们需要一个易维护且性能好的请求体构建工具。下面这个是我项目里用得很顺手的轻量方案。

public class ChatRequestBodyBuilder { private final StringBuilder body; private int messageCount = 0; public ChatRequestBodyBuilder(int capacity) { this.body = new StringBuilder(capacity); body.append("{\"model\":\"gpt-xxx\",\"messages\":["); } public ChatRequestBodyBuilder addMessage(String role, String content) { if (messageCount > 0) { body.append(","); } body.append("{\"role\":\"") .append(role) .append("\",\"content\":\"") .append(escapeJson(content)) .append("\"}"); messageCount++; return this; } public ChatRequestBodyBuilder addSystemPrompt(String prompt) { return addMessage("system", prompt); } public ChatRequestBodyBuilder addUserInput(String input) { return addMessage("user", input); } public ChatRequestBodyBuilder addAssistantReply(String reply) { return addMessage("assistant", reply); } public String build() { body.append("],\"temperature\":0.7}"); return body.toString(); } private String escapeJson(String text) { // 这里需要把文本中的引号、反斜杠、换行符等转义，避免破坏JSON结构 // 一般用JSON库的escape方法或自己写个简单替换 return text.replace("\\", "\\\\") .replace("\"", "\\\"") .replace("\n", "\\n"); } }

这段代码有几个设计点值得说明。第一，容量参数由调用方预估，避免扩容。第二，addMessage方法可以被链式调用，代码可读性好。第三，转义逻辑单独抽出，保证JSON结构不被用户输入破坏。实际使用时，如果请求体结构复杂，我仍然建议直接用Jackson序列化对象，更不容易出错。但轻量场景下，这种构建器确实比JSON序列化更快、更节省内存。

5.2 多轮会话上下文的ArrayList管理

AI应用里经常会做一个“上下文窗口”功能，只保留最近N条消息。用ArrayList+头部删除虽然能实现，但性能不佳。更好的做法是用ArrayDeque或者自定义循环逻辑。

一个简单且高效的实现是使用ArrayDeque：

import java.util.ArrayDeque; import java.util.Deque; public class ConversationWindow { private final Deque<String> messages = new ArrayDeque<>(); private final int maxSize; public ConversationWindow(int maxSize) { this.maxSize = maxSize; } public synchronized void addMessage(String message) { if (messages.size() >= maxSize) { messages.pollFirst(); } messages.offerLast(message); } public synchronized List<String> getAllMessages() { return new ArrayList<>(messages); } }

ArrayDeque的头尾操作都是O(1)，所以无论窗口多大，新增消息淘汰旧消息都很快。而且这里用了synchronized保证多线程下的并发安全，虽然Api接口调用通常是请求线程内独立操作，但加上锁更稳妥。

当然，如果对顺序要求不那么严格，或者只是一个线程在写入、主线程在读取，还可以考虑ConcurrentLinkedDeque，性能更好。

5.3 接口异常信息处理中的字符串操作

之前在热搜词里看到api error: 529 overloaded这个报错，这是服务器过载的提示。我们在写AI应用时，经常要捕获这些异常信息并提取关键内容做错误处理。这就要用到String的查找、截取、替换等操作。

比如错误响应体可能长这样：

{"error": {"message": "The server is overloaded", "type": "server_error", "code": 529}}

要提取message字段，简单的做法：

String response = "{\"error\": {\"message\": \"The server is overloaded\", \"type\": \"server_error\", \"code\": 529}}"; String field = "\"message\":\""; int start = response.indexOf(field) + field.length(); int end = response.indexOf("\"", start); String message = response.substring(start, end);

但更可靠的做法是用JSON库解析，然后取字段。直接用substring处理字符串对简单场景有效，但一旦JSON结构变化（比如字段顺序调整），代码就崩了。实际工程里，能用JSON库就用JSON库，Substring只适用于格式极其稳定的场景。

5.4 日志拼接的最优实践

日志是排查AI应用问题的第一手段，但日志里的字符串拼接也容易写错。我经常看到有人这样写：

logger.info("request param: " + userId + ", " + prompt + ", " + temperature);

这个写法不管日志级别是否开启，都要先执行字符串拼接，白白浪费性能。正确写法是用日志框架的占位符：

logger.info("request param: {}, {}, {}", userId, prompt, temperature);

占位符写法在日志级别不匹配时，不会执行字符串拼接，性能更好。而且日志框架对占位符参数的toString调用是延迟到真正输出时才执行的，能省去不必要的对象创建。

5.5 面试题速查：String vs StringBuilder vs StringBuffer

既然热搜词里大量出现“java面试题”“java八股文”，这里顺手整理一个高频题版本的对比，供大家复习用。

面试追问的点通常是：为什么StringBuilder比String拼得快？这个回答的关键是“String拼接会产生新对象，StringBuilder在原数组上追加”。再深一层会问扩容机制和HashCode问题，答出“String的hashCode被缓存”这个点也能加分。

6. 常见问题与排查技巧实录

这一节把我实际开发中遇到的问题和排查思路整理一下，很多都是代码走查时发现的典型case。

6.1 字符串拼接导致内存溢出

有一个服务用来批量生成AI训练用的prompt模板，单条文本几十KB，一次要生成几千条。原始代码用String在循环里拼，结果线上频繁出现OutOfMemoryError: Java heap space。

排查步骤：

1. 先看GC日志，发现Young GC频率极高，老年代也在持续增长。
2. jmap dump出堆快照，用MAT分析，发现大量char[]对象，都是StringBuilder toString的残留。
3. 定位代码，发现是循环内用String result += text的方式累积。

修复方式很简单，改用StringBuilder并在循环外创建。修复后GC频率大幅下降，OOM不再出现。

这里有个细节：String的+=在字节码层面会new一个StringBuilder，循环里每次都new，对象创建数量是循环次数乘以2~3。一旦对象进入老年代，GC成本就很高。

6.2 ArrayList在并发add时数据丢失

一个AI网关服务里，多个线程并发调用大模型接口，然后把结果add到一个共享ArrayList里。上线后发现列表里有的结果丢了，或者数据错乱。

原因很简单，ArrayList的add不是原子的。两个线程同时add时，可能都读到了同一个size，然后都往同一个索引位置写，另一个位置的写入就被覆盖了。修复方式有两个方向：

一是换线程安全的集合，比如CopyOnWriteArrayList，但前面说过写多场景不适合。二是在add外层加锁，或者改用ConcurrentLinkedQueue收集结果，最后批量转成ArrayList。

我最后用的是ConcurrentLinkedQueue配合批量转List，写性能高，且不需要阻塞，实测在几十个并发请求下表现稳定。

6.3 JSON字符串转义导致请求失败

调用大模型API时，用户输入里带引号、换行符、反斜杠是常见现象。如果直接拼进JSON字符串里，会导致JSON解析失败，接口返回400。

这个坑在代码里通常表现为：明明本地测试没问题，测试环境也正常，一到线上某个用户输入特殊字符就报错。

解决办法就是前面给的escapeJson方法。需要转义的字符包括：反斜杠、双引号、换行符\n、回车符\r、制表符\t、退格符\b、换页符\f，以及一些特殊控制字符。用JSON库的序列化功能最稳妥，自己手写转义容易漏。

6.4 字符串split的奇怪行为

Java的String.split方法有一个容易误用的点：它是基于正则表达式的。比如想按"."切分IP地址：

String ip = "192.168.1.1"; String[] parts = ip.split(".");

结果得到一个空数组。因为.在正则里是“匹配任意字符”的通配符，所以整个字符串被每个字符切开了。正确写法是ip.split("\\.")，对正则元字符用双反斜杠转义。

同样的问题还有"|"、"*"、"+"、"?"这些正则元字符。遇到这个坑时，可以用Pattern.quote(".")来得到字面量匹配模式，或者直接用split之前先replace。

6.5 String.valueOf和toString的区别

String.valueOf(Object obj)和obj.toString()在大多数场景下结果一样，但有边界情况。valueOf的实现是：

public static String valueOf(Object obj) { return (obj == null) ? "null" : obj.toString(); }

所以当对象是null时，valueOf返回字符串"null"，而直接调用obj.toString()会抛NullPointerException。在拼日志、拼提示词时，用String.valueOf比直接toString更安全。

6.6 List转数组的坑

ArrayList转数组有toArray()和toArray(T[] a)两个版本。直接用无参版本得到Object[]，往里面塞String会报ClassCastException。正确做法是：

List<String> list = new ArrayList<>(Arrays.asList("a", "b")); String[] array = list.toArray(new String[0]);

JDK 8之后传入new String[0]比传入指定大小的数组更高效，因为底层会判断如果传入数组容量不够，就重新创建合适大小的数组，指定大小反而多一次计算。

6.7 容量预分配的经验值

关于Capacity预分配，我总结了一套经验值。拼接JSON请求体，一般不超过2KB，给512~1024。拼接响应日志行，预估每行1KB，给1024。上下文窗口的字符串拼接，根据窗口大小和单条消息长度预估，一般给窗口数 * 单条平均长度 * 1.2。

设置容量时不用过于精确，大方向是“避免扩容”，而不是“恰好够用”。多给20%~50%的余量是合理做法。

7. 细节优化与日常习惯

7.1 关于字符串常量池的补充知识

字符串常量池在JDK 7之后移到了堆里，这意味着常量池里的字符串可以被GC回收。理解这一点后，还有一个实际影响：大量使用new String("xxx")会产生重复字符串对象，但不会复用常量池里的内容。

String的+号拼接有一个编译器优化规则。如果+的两端都是字面量常量，比如"a" + "b"，编译器会在编译期直接合并成"ab"存到常量池。但如果是变量拼接，编译器会生成StringBuilder代码。所以下面这两种写法性能上是一个量级：

String s = a + b; // 字节码层面是 new StringBuilder(a).append(b).toString() StringBuilder sb = new StringBuilder(); sb.append(a).append(b); String s2 = sb.toString();

Java编译器其实已经做了StringBuilder优化，所以简单的拼接不需要刻意改写法。问题出在循环里，因为编译器不会把循环体内的StringBuilder提升到循环外。

7.2 避免无意义的自动装箱和字符串转换

ArrayList声明时如果不指定泛型，会默认存Object，取出来要强转。在AI应用里，尽量用泛型明确类型，比如List<String>、List<Map<String, Object>>，减少类型转换和ClassCastException。

另外，拼接数字时用String.valueOf或者直接"" + number，要注意"" + null得到的是"null"字符串，如果业务上不期望如此就要提前判空。

7.3 从热词“AI八股文”说起

这些基础类在AI应用的面试题里占了相当大比例。算法题不一定考，但String不可变性、ArrayList扩容机制、HashMap实现原理这些几乎是必问。我见过不少简历上写“精通Java”的候选人，倒背如流hashmap红黑树，但写代码时list遍历删除都翻车，这类基础知识反而最能反映实际水平。

与其背八股文，不如在项目里多用几次StringBuilder做性能对比，实际感受一下不同写法带来的差异。纸上得来终觉浅。

8. 基于个人实践的几个最后建议

我在实际项目中踩过很多次String拼接的坑，最深刻的体会是：性能问题往往不是由单一一次操作引起的，而是由大量简单操作的累积效应造成的。一次字符串拼接可能只差零点几微秒，但循环一万次、QPS上千时，差距就会被放大。

这也解释了为什么大厂面试常问基础API。String、StringBuilder、StringBuffer和ArrayList这几个类，几乎覆盖了Java日常开发的半壁江山。把这几个类的底层原理吃透，很多看似玄学的性能问题都能迎刃而解。真正写代码时，把“用对应场景的工具解决对应场景的问题”这个原则刻在脑子里，就能避免多数常见的坑。