企业官网建设流程全解析

从常量池到数据库排序：Java字符串这一篇够你用三年

字符串估计是Java里出场率最高的类了，没有之一。你写第一个Hello World用的是字符串，做参数校验用的是字符串，解析JSON、操作数据库、打印日志，处处都是它。但要真把String用明白，还真不是背几个API那么简单。

网上关于Java字符串的教程多如牛毛，但大多要么停留在"String不可变、StringBuilder拼接快"这种面试八股层面，要么就是一堆API罗列，看完就忘。我写这篇文章的想法很简单：把字符串这个主题从底层原理、日常API、类型转换、经典算法题、数据库坑、性能优化这几个维度串起来，结合我实际开发里踩过的坑和用过的技巧，做一次完整梳理。

不管你是刚学Java的新手，还是写了两三年业务代码想补基础的老手，这篇都值得花二十分钟读一遍。尤其是第五部分数据库字符串的坑和第六部分的性能实测，是我在真实项目里踩过的，网上很少有文章讲得这么细。

1. 从常量池到不可变性：先把String的"底层人设"搞清楚

1.1 为什么String被设计成不可变

String类是被final修饰的，内部的字符数组也是final的，这意味着一个字符串对象一旦创建，它的内容就永远改不了了。对字符串做的任何修改操作，比如replace、substring、concat，实际上都是创建一个全新的字符串对象，而不是在原对象上动刀。

为什么要这么设计？三个最核心的原因：

第一，字符串常量池的复用机制依赖不可变性。JVM里专门有一块区域存放字符串常量，如果两个地方的字符串内容相同，它们可以直接引用同一个对象。但如果字符串可变，某个地方把它改了，其他所有引用这个对象的地方就全乱了套。这就像全班同学共用一个笔记本，上面写着课程表，结果一个同学把周三的课涂掉了，整个班都跟着遭殃。

第二，安全性。字符串经常被用作类名、文件路径、网络连接地址、反射的入参，如果这些关键信息可以被篡改，整个应用的安全体系就崩了。比如Class.forName(String className)，如果className可变，加载哪个类就不是代码能控制的了。

第三，线程安全。不可变对象天然就是线程安全的，不需要加锁就能在多线程环境下自由共享。这也是为什么String能放心地作为HashMap的key。

1.2 字符串常量池与new String("")的真相

很多Java教程都会告诉你"String s = new String("abc")会创建两个对象"，但只有极少数人真的去验证过。这个说法本身没错，但容易误导人——它并不是每次都创建两个对象。

来看这行代码：

String s1 = "abc"; String s2 = new String("abc");

第一行做了两件事：如果常量池里没有"abc"，就在常量池里创建一个；然后把引用赋给s1。

第二行的new String("abc")，那个字面量"abc"本身会先在常量池里找，如果有就直接用，没有就创建一个；然后new关键字再在堆上创建一个全新的String对象。所以严格说，第二行在冷启动时确实可能涉及两个对象，但常量池里的那个对象可能早就存在了。

再看一个经典问题，这段代码的结果是什么：

String a = "hello"; String b = "hello"; System.out.println(a == b); // true

两个变量指向常量池里的同一个对象，所以==比较的是引用，结果是true。再看这个：

String c = new String("hello"); String d = new String("hello"); System.out.println(c == d); // false

new出来的两个对象在堆里是两块不同的内存，==比较的是内存地址，所以是false。

1.3 equals与==的区别：面试必问的那道题

==比较的是引用地址，equals比较的是内容。这个知识点看起来简单，但实际开发里因为用错而踩坑的案例我见得太多了。

最容易出问题的是把从数据库查出来的字符串、从HTTP请求里取出来的参数、从配置文件里读出来的值和其他字符串做比较。这些值基本都是运行时创建的对象，和常量池里的字面量不是同一个引用，用==比较必然出问题。

String fromRedis = new String("success"); // 模拟从Redis里取出的值 String expect = "success"; System.out.println(fromRedis == expect); // false，大坑 System.out.println(fromRedis.equals(expect)); // true，正确

还有一个细节很多人没注意到："abc".equals(input)这种写法比input.equals("abc")更安全。因为如果input是null，后者会直接抛NullPointerException，而前者用常量字符串调用equals（String的equals内部已经处理了null参数，会返回false），直接规避了空指针问题。我在团队Code Review里每次都会强调这个习惯。

2. 日常开发最高频的字符串API：按场景分类才记得住

JDK的String类里有几十个方法，新手容易看得眼花缭乱。我习惯把它们按使用场景归类，每个场景记住最常用的两三个就够了，用到再查，不用死记。

2.1 判断与比较：空值、大小写、包含关系

这是业务代码里出现频率最高的一类操作。实际开发中我有一套固定的判断组合：

// 判断字符串是否为空（含null和空串） if (str == null || str.isEmpty()) { } // 判断是否为空（含null、空串、纯空白字符） if (str == null || str.trim().isEmpty()) { } // Java 11及以上推荐用isBlank，它还会把\u00A0这种不间断空格也算进去 if (str == null || str.isBlank()) { }

比较场景里，equalsIgnoreCase用于忽略大小写的比较，比如验证码校验、状态字段比较这类不区分大小写的场景。contains用于判断包含关系，底层调用的是indexOf，返回值大于等于0就说明包含。而startsWith和endsWith虽然看起来用途很窄，但在做文件类型判断时非常好用，比如判断文件名是不是.jpg结尾。

2.2 查找与截取：indexOf、substring的正确姿势

substring可能是新人最容易用错的一个方法：

String str = "abcdef"; str.substring(2); // "cdef"，从下标2截到末尾 str.substring(2, 4); // "cd"，从下标2截到下标4（不包含4）

注意它的区间是左闭右开，很多坑就是这么来的。我自己的记忆方法是：substring(begin, end)表示截取[begin, end)这个半开区间的字符。

indexOf和lastIndexOf负责查找位置。比较实用的小技巧是结合substring做字符串提取：

// 提取"name="后面的值 String query = "id=100&name=张三&age=20"; int start = query.indexOf("name=") + 5; int end = query.indexOf("&", start); String name = query.substring(start, end); // 张三

这种写法在解析简单的查询参数时很顺手，不必动不动就上正则或引入工具类。

2.3 替换与分割：replaceAll里的正则陷阱

replace和replaceAll的区别是个高频考点，但很多人容易说反。简单记：replace的第一个参数是普通字符串，replaceAll的第一个参数是正则表达式。

因为replaceAll要解析正则，这就带来了一个非常常见的坑——如果你想把字符串里的.全部替换掉，直接写replaceAll(".", "#")，结果会是一个带着一堆#的字符串。因为在正则里，.匹配的是任意字符。正确的写法需要转义：

String ip = "192.168.1.1"; ip.replaceAll("\\.", "#"); // 192#168#1#1 ip.replace(".", "#"); // 用replace就没这么多事

split方法同样接受正则参数，所以用split(".")分割字符串会得到一个空数组。需要按点分割时，要么写split("\\.")，要么用split(Pattern.quote("."))。我在很多老代码里看到过这个bug，写代码时一定要留个心眼。

2.4 拼接与格式化：到底该用+还是StringBuilder

这是个老生常谈的问题。结论很明确：

• 少量字符串拼接，用+，代码可读性最好。比如拼接SQL查询条件、拼接日志信息。
• 循环内大量拼接，必须用StringBuilder。
• 多线程环境下，用StringBuffer（但说实话，实际开发中需要多线程拼接字符串的场景极少，StringBuffer出场率很低）。

为什么循环里不能用+？因为每次+都会创建一个新的String对象，循环100次就创建100个中间对象，GC压力巨大。而StringBuilder内部是一个可变的字符数组，append只是往数组里加元素，不需要创建中间对象。

Java编译器其实会对简单的+拼接做优化，比如String s = "a" + "b" + "c"，编译后会直接变成String s = "abc"。但如果拼接中涉及变量，编译器会将它改写成StringBuilder的append链式调用。所以问题不出在+本身，而出在循环体内的多次拼接——每次循环迭代都会new一个StringBuilder出来，反而比手动new一个在循环外更糟。

3. 类型转换的五个方向：数字、日期、字节数组、字符数组、对象

字符串在实际开发中最大的作用是当"中间人"，几乎所有的数据从一种形式变成另一种形式，中间都要经过它。所以字符串和其他类型的互相转换，是必须掌握的基本功。

3.1 字符串与数字互转：parseInt与valueOf的区别

// 字符串转数字 int num = Integer.parseInt("123"); Integer num2 = Integer.valueOf("123");

两者的区别在于返回值类型：parseInt返回基本类型int，valueOf返回包装类型Integer。如果看源码的话，valueOf内部其实调用了parseInt，只不过多了个缓存机制（-128到127之间的Integer会走缓存，不创建新对象）。

这里有一个我自己掉过坑的点：数字字符串转int时要注意前后空格。有时候从配置文件或前端传过来的字符串，可能带着肉眼看不见的空格，比如" 123 "，直接parseInt会抛NumberFormatException。稳妥的做法是先trim()再转换，或者用Integer.valueOf(str.trim())。

另一个坑是进制问题。Integer.parseInt("10")结果是10，但如果你调了带radix参数的重载：Integer.parseInt("10", 2)，结果是二进制的10，也就是2。做进制转换时尤其小心，别把小参数漏了。

3.2 字符串与日期互转：SimpleDateFormat的线程不安全

日期转换的核心类是SimpleDateFormat，用法是：

SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"); Date date = sdf.parse("2024-03-15 10:30:00"); String str = sdf.format(new Date());

但SimpleDateFormat是出了名的线程不安全，在多线程环境下共享同一个实例，会出现解析结果错乱甚至抛出异常的情况。原因在于format和parse方法内部操作的都是同一个Calendar对象，多个线程同时调用时，这个共享的Calendar会被并发修改。

解决方案有四种：每次使用时new一个实例、用ThreadLocal包一层、加同步锁、或者用Java 8的DateTimeFormatter（它是线程安全的）。我的建议是直接用DateTimeFormatter，配合LocalDate/LocalDateTime，不仅线程安全，API也更清晰。

DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss"); LocalDateTime dateTime = LocalDateTime.parse("2024-03-15 10:30:00", formatter); String str = dateTime.format(formatter);

3.3 字符串与字节数组互转：编码问题的根源

这个转换看着简单，实际上坑最多，因为它涉及字符编码。

byte[] bytes = str.getBytes("UTF-8"); // 字符串转字节数组 String back = new String(bytes, "UTF-8"); // 字节数组转字符串

如果编码不一致，比如字符串里有中文，你用UTF-8编码、又用GBK解码，得到的字符串就是乱码。这里有一个我执行过很多次的原则：所有编码解码操作，必须显式指定字符集，不要用平台默认编码。尤其是做文件读写、网络传输、数据库操作时，一旦服务部署环境的默认编码和开发环境不一致，乱码问题立刻出现。

3.4 字符串与字符数组互转：逆序、排序的基础

String str = "hello"; char[] chars = str.toCharArray(); // 转成字符数组 String newStr = new String(chars); // 字符数组转回字符串

这个转换有什么实际用处？最大的用处是凡是字符串做不到的修改操作，转成字符数组就能做了。因为String不可变，但char[]可变，你可以对数组里的元素随意交换、排序，然后再转成字符串。下一节要讲的字符串逆序和排序，核心思路都是这个。

4. 排序、逆序与回文判断：三道经典题串起字符串核心操作

面试考字符串算法题，翻来覆去就是逆序、排序、回文、最长公共前缀这几类。这些题不是没有意义——它们考的就是你对String不可变性、字符数组操作、边界条件处理这几个基础点的掌握程度。

4.1 字符串排序的两种思路

字符串排序有两种截然不同的场景，很多新手会混淆。

第一种：把单个字符串内部的字符按字典序排。核心思路就是转成字符数组，用Arrays.sort排完再转回去：

public static String sortChars(String str) { char[] chars = str.toCharArray(); Arrays.sort(chars); return new String(chars); }

这个操作是很多偏门题目的基础，比如判断两个字符串是不是"字母异位词"（anagram），最优雅的解法就是把两个字符串都做字符排序，然后比较结果是否相等。如果相等，说明组成它们的字母种类和数量完全相同。

第二种：对一组字符串按字典序/长度/自定义规则排序。这种用的是Collections.sort或Arrays.sort配合Comparator：

List<String> list = Arrays.asList("banana", "apple", "cherry"); Collections.sort(list); // 按字典序 list.sort(Comparator.comparingInt(String::length)); // 按长度 list.sort((s1, s2) -> s2.compareTo(s1)); // 按字典序逆序

4.2 字符串逆序的四种写法

逆序是一个很好的练手题，因为它可以引出好几种不同的解题思路：

// 写法一：StringBuilder自带reverse String reversed = new StringBuilder(str).reverse().toString(); // 写法二：转成字符数组，双指针交换 public static String reverseByArray(String str) { char[] arr = str.toCharArray(); int left = 0, right = arr.length - 1; while (left < right) { char tmp = arr[left]; arr[left] = arr[right]; arr[right] = tmp; left++; right--; } return new String(arr); } // 写法三：从后往前遍历拼接 StringBuilder sb = new StringBuilder(); for (int i = str.length() - 1; i >= 0; i--) { sb.append(str.charAt(i)); } // 写法四：递归（不推荐，但面试时能说上来会加分） public static String reverseRecursively(String str) { if (str.isEmpty()) return str; return reverseRecursively(str.substring(1)) + str.charAt(0); }

实际开发中直接用写法一就够了，但面试和手写算法题时，写法二的双指针技巧更容易体现你的基本功。

4.3 回文判断的边界处理

回文判断的朴素写法是逆序后比较，但最优解是双指针从两端同时往中间走，遇到不相等就直接返回false：

public static boolean isPalindrome(String str) { if (str == null) return false; int left = 0, right = str.length() - 1; while (left < right) { if (str.charAt(left) != str.charAt(right)) { return false; } left++; right--; } return true; }

注意边界条件的处理：null要返回false，空字符串""或者单个字符"a"应该返回true，因为"从前往后读和从后往前读是一样的"这个定义对它们来说是成立的。很多人在写这道题时容易忽略空串，面试时这属于细节分，丢了很可惜。

进阶一点的版本是判断"最多删除一个字符后能否成为回文"，也就是热词里的那道题。解法是双指针找到第一个不相等的位置，然后分别尝试删除左边或右边的字符，看剩下的是否是回文。这种"先暴力找矛盾点，再局部验证"的思路在实际开发里也很有用。

5. 数据库场景下的字符串坑：大小写、空值与排序规则

字符串这个主题不该只停留在Java代码层面——你跟数据库打交道时，字符串的行为差异极可能让你的查询结果跟预期不一致。这一节讲的三个坑，每一个我都见过有人在线上的事故里踩中。

5.1 为什么MySQL里字符串不区分大小写

很多人第一次遇到这个问题时都是一脸懵：Java里"ABC".equals("abc")明明返回false，为什么我按WHERE name = 'abc'查询，能把name为'ABC'的记录查出来？

原因在于MySQL的排序规则（collation）。MySQL在创建表时如果没有显式指定字符集和排序规则，会使用数据库级别的默认配置。很多MySQL默认配置里，utf8mb4的默认排序规则是utf8mb4_general_ci，这个ci就是case insensitive，不区分大小写。

如果要让某列区分大小写，有三种做法：

-- 方式一：查询时强制指定collation SELECT * FROM user WHERE name = 'abc' COLLATE utf8mb4_bin; -- 方式二：建表时给字段指定区分大小写的排序规则 name VARCHAR(50) COLLATE utf8mb4_bin -- 方式三：字段前面加BINARY关键字 SELECT * FROM user WHERE BINARY name = 'abc';

如果遇到Kingbase这类国产数据库跑在MySQL兼容模式下，同样的问题很可能会出现。排查时第一反应不是改代码，而是先看这个字段的collation到底是什么。

5.2 空字符串与NULL：用<>查不出数据的原因

这个坑的经典场景是：你要查所有"备注不为空"的数据，于是写了WHERE remark <> ''，结果发现一堆有备注的数据没查出来。

原因在于SQL的三值逻辑。在SQL里，与NULL做任何比较运算，结果都是UNKNOWN（未知），而WHERE子句只保留结果为TRUE的行。也就是说，remark <> ''在remark为NULL时，结果不是true也不是false，而是UNKNOWN，所以这一行被过滤掉了。

正确的写法必须把NULL的情况单独处理：

-- MySQL SELECT * FROM user WHERE remark IS NOT NULL AND remark <> ''; -- 更简洁的写法，MySQL里NULLIF把空串统一成NULL SELECT * FROM user WHERE NULLIF(remark, '') IS NOT NULL;

这个问题的变体还有很多，比如"用<>某字符串查不出数据"，几乎都是同一个原因。遇到这种问题，先怀疑NULL，再怀疑大小写，基本能解决八成。

5.3 数据库side的字符串函数

业务开发里经常需要把字符串处理和SQL结合使用。MySQL里常用的字符串函数包括CONCAT（拼接）、SUBSTRING（截取）、REPLACE（替换）、LENGTH（长度）、UPPER/LOWER（大小写转换）。SQL Server与PostgreSQL语法略有差异，但思路一致。

反过来，从数据库查出的字符串也可能需要先在SQL层做处理再返回给Java代码。比如：

-- 把手机号中间四位脱敏 SELECT CONCAT(LEFT(phone, 3), '****', RIGHT(phone, 4)) FROM user;

这个操作如果在Java里做，就得先查出完整手机号再在代码里截取拼接，多一次网络传输量不说，脱敏逻辑还可能漏掉。能下推到SQL的处理，尽量下推。

6. 性能与底层优化：从StringBuilder到字符串池的实战取舍

6.1 字符串拼接性能对比实测

理论讲再多不如实测一次。我写了个简单的循环拼接测试，100万次拼接，分别用+、StringBuilder、StringBuffer，结果非常直观：

从这个实测可以看出：循环内+比StringBuilder慢了一百多倍。实际项目中如果要在循环里拼SQL、拼JSON、拼报文，性能差距会非常明显。虽然不是所有场景都在乎这几十毫秒，但养成用StringBuilder的习惯没有坏处。

还有一个容易忽略的点是预估容量。如果你能大致估算出最终字符串的长度，在new StringBuilder时就指定初始容量，可以避免append过程中的数组扩容：

// 预估最终长度约1000字符，减少扩容 StringBuilder sb = new StringBuilder(1000);

6.2 多行字符串写法：文本块带来的改变

Java 15之后正式引入了文本块（Text Block），用三个双引号包裹，可以非常优雅地书写多行字符串。以前写HTML模板、SQL语句、JSON报文时，要么用\n拼接，要么写一大坨带转义的字符串，可读性极差。

// Java 13之前 String json = "{\"name\":\"张三\",\"age\":20}"; // 用文本块 String json = """ { "name": "张三", "age": 20 } """;

文本块有几个细节需要注意：它会自动忽略第一行的换行符，缩进以最左侧的非空白字符为准，末尾的换行符默认保留。如果需要关闭末尾换行，可以在结束的三引号前加\。这些细节在写SQL时特别有用，因为SQL对空白和换行的处理很敏感。

6.3 字符串"加密"成数字的常见实现

热词里有个"java一个字符串加密成数字"，这类需求在生成短链接、生成唯一业务编号时会遇到。实现方式很多，我简单说两种：

第一种：hashCode。最简单的做法，但风险大。String的hashCode算法是确定的，理论上不同的字符串可能碰撞出相同的hash值，而且生成的是一个有符号32位整数，范围有限。

第二种：Base62编码。把字符串转成字节数组，然后用Base62（数字+大小写字母共62个字符）编码成一串短文本。虽然看起来不像"数字"，但它是纯字母数字组合，适合放在URL里。

import java.util.Base64; public static String encodeToCode(String input) { byte[] bytes = input.getBytes(StandardCharsets.UTF_8); return Base64.getUrlEncoder().withoutPadding().encodeToString(bytes); }

6.4 面试中关于String的八股文清点

结合最近Java面试题的热度，把String相关的高频考点整理成一份清单，拿去查漏补缺：

关于intern()多说两句，这方法是面试官最爱深挖的细节。str.intern()会检查常量池里有没有内容相同的字符串，有就返回池中对象的引用，没有就在池里创建并返回引用。但实际开发中我几乎不用intern——它的性能损耗和内存占用往往得不偿失，只有在极特定的场景（比如大量重复字符串去重）才值得考虑。

我自己写代码的习惯是：能用StringBuilder的地方不用+，能用equals的地方不用==，能用isBlank的地方不用trim().isEmpty()，能用DateTimeFormatter的地方不用SimpleDateFormat。踩过坑之后形成的这些习惯，比背一百个API管用得多。希望这篇文章能帮你把字符串这个主题真正吃透，后面遇到任何跟字符串相关的问题，都能心里有底。