当学到Java基础中间阶段多半会碰到两个绕不开的名字Object和String。很多人对它们的认知停留在Object是所有类的父类String是不可变的然后就去背面试题了。但实际写代码时equals和用错、循环里拼字符串导致接口变慢、hashCode没跟着equals重写结果HashMap查出两个一模一样的 key……这些坑我几乎每周都能在同事的代码里见到一次。这篇文章不打算按教材顺序罗列方法清单而是把Object和String放到真实的使用场景里拆开讲Object里那几个方法分别解决什么痛点、为什么hashCode和equals必须成对出现、String 的不可变性到底换来了什么、什么时候该用StringBuilder而不是继续。同时会补上一些日常代码里高频踩中的 String 陷阱比如split的正则转义、replace和replaceAll的区别这类细节。适合刚学完Java语法、正在往集合与容器方向过渡的初学者也适合想把这些基础概念真正用对的开发者做一次系统梳理。1. Object类为什么所有类都得认这个祖宗1.1 一个被反复忽视的问题没有Object会怎样很多人第一次听说所有类都继承 Object时只是把它当作一条需要记忆的规则。真正的问题是Java 的设计者为什么非要搞出这么个公共父类不可试着想象一个没有Object的世界。你写了一个ArrayList想让它既能存Student对象又能存Order对象。没有公共根类型的话你得为每一种类型单独写一个集合类这显然不现实。有了Object之后ArrayListObject这种写法才成立——任何一个类的实例都能向上转型成Object容器只需要面向Object编程就行。再想一层Java 的线程同步机制里synchronized关键字可以锁住任意对象靠的正是所有对象都有一个公共的监视器概念垃圾回收器在回收前判定对象是否还有引用也依赖统一的根类型体系。Object就像是整个对象世界的身份证系统——无论你是什么类的实例最终都能被归到同一个大类里去统一管理。1.2 Object类到底内置了哪些方法它们各自是干嘛的Object类里方法不多但每一个都是细思极恐级别的设计。大致可以分为三组分组方法核心作用对象身份与信息getClass()、toString()获取运行时类信息、返回对象的字符串描述相等与哈希equals(Object)、hashCode()判定逻辑相等、计算哈希值并发与生命周期wait()、notify()、notifyAll()、finalize()线程协作等待唤醒、对象回收前的回调getClass()平时用得不算多但它是反射的入口之一。比如你写了一个参数为Object的方法想根据实际类型走不同逻辑可以这样判断obj.getClass() Student.class。它返回的Class对象和instanceof的区别在于——getClass()做的是严格的运行时类型比较不受继承关系影响。finalize()在旧版 JDK 里常被误用来做资源释放比如在对象回收前关掉流。这种做法现在已经被明确标记为不推荐因为它的执行时机不确定还可能延长对象的生命周期反而拖慢 GC。除非你在读非常古老的 Java 代码否则基本可以忽略这个方法。1.3 toString的默认行为以及为什么日志里会看到一串类名哈希不经重写直接打印对象时输出通常是com.example.Student3c1bbcd0这种格式。它由三部分组成类全名 十六进制的hashCode。这段信息对调试基本没有帮助——你想看的是学生的姓名和分数而不是内存地址的某种表现。所以实际项目里最常见的重写之一就是toString()。别小看这个细节打印日志时如果toString写得好排查起问题来效率能差出好几倍。推荐格式是尽量把关键字段都带上比如Override public String toString() { return Student{name name \ , score score }; }如果是用 IDE 自动生成的代码它在拼接时还会用StringBuilder来优化这也是为什么看 IDE 生成的toString不会是一长串直接连到底。从 JDK 17 开始可以用record声明简单数据类编译期会自动生成合理好用的toString、equals、hashCode覆盖了不少手动重写的场景。但老代码里的类依然很多手动重写的功底还是得会。2. hashCode与equals面试常考但更重要的是哈希表会真的出bug2.1 equals的默认语义和内容相等之间的鸿沟在没有重写的情况下equals的行为就是比较两个引用是否指向同一个对象。同一份数据 new 了两个对象出来内容一模一样equals照样返回false。这很容易踩中直觉陷阱——同一个学生信息从数据库查一次生成一个对象你凭什么说它们不是同一个学生这也是为什么重写equals成了 Java 基础里的标配操作。但真正的难点在于规则约定一旦重写了equals就必须同时重写hashCode否则基于哈希的集合类会悄悄出错。2.2 不重写hashCode的后果HashMap里的李鬼问题先看一个具体场景。你有一个Student类只重写了equals按学号和姓名比较没重写hashCode。然后把它放进一个HashSetSetStudent set new HashSet(); set.add(new Student(001, 张三)); set.add(new Student(001, 张三)); System.out.println(set.size()); // 你预期是1实际可能是2HashSet的底层是HashMap它定位元素靠的是哈希值。两个equals相等的对象如果没有相等的hashCode就会被散列到不同的桶里根本不会触发equals比较。换句话说逻辑上相同的两个人在集合里被当成了两个不同的人。反向也可能出问题你查Map.get(key)时传入的 key 和存储的 key 明明equals为true但因为 hashCode 不同连最初的定位都错位了返回null。这种 bug 非常阴险代码里看起来哪哪都对运行结果就是不对。2.3 重写的标准姿势字段选择、类型判断、计算散列业界比较通用的写法是Override public boolean equals(Object o) { if (this o) return true; if (o null || getClass() ! o.getClass()) return false; Student student (Student) o; return score student.score Objects.equals(name, student.name) Objects.equals(id, student.id); } Override public int hashCode() { return Objects.hash(id, name, score); }有几个点值得展开。getClass() ! o.getClass()和o instanceof Student怎么选如果是严格的同类型比较用前者能避免子类破坏对称性如果业务上允许子类对象互相等同才考虑用instanceof。多数业务场景我建议用getClass()更稳妥。Objects.hash()的底层会把每个字段依次叠进去用 31 作为质数加权。为什么是 31因为31 * i可以用位运算(i 5) - i近似替代既保证散列分布相对均匀又让计算足够便宜。这也是 Java 设计里一个很经典的性能与质量折中。还有一点容易忽略equals比较的字段和hashCode参与计算的字段必须保持一致。如果你在 equals 里比了discount但 hashCode 只算了id同样会导致两个逻辑相等的对象哈希不同。这块的一致性审查code review 时值得每次多看一眼。3. String的设计哲学不可变性换来的安全与共享3.1 三种创建方式两种存储位置String 的创建方式看起来只是写法的差异实际涉及 JVM 内存布局。逐一说String s1 hello;如果常量池里没有helloJVM 会在字符串常量池中创建对象然后栈上的引用直接指向池中对象。String s2 new String(hello);无论如何都会在堆上 new 出一个新对象同时可能把hello这个字面量也放入常量池。也就是双对象——一个池中对象一个堆内对象。s1.intern()主动把字符串内容加入常量池并返回池中对象的引用。理解了这个比较字符串的问题就清楚了s1 s2一般情况下是false因为两边存的引用根本不是一个对象。但是s1 hello却可能是true因为字面量都被池化了。实际开发里字符串内容比较永远用equals这不是保守而是因为内容相等的语义从来不该依赖引用地址。3.2 不可变性不是限制而是整个共享机制的前提String 的不可变性体现在类本身是 final 的、内部字段是 final 的、substring等操作不会改动原对象而是返回新对象。很多人只把它当作一条结论背看不到背后的设计逻辑。试想如果字符串是可以修改的那常量池的缓存共享直接崩掉——两个不同代码位置引用了同一个hello其中一处把内容改成了world另一处也会被波及。这跟全局变量被到处改一样可怕。不可变性还带来一个实际收益哈希缓存。String 内部缓存了自身的 hash 值因为是 final 的所以只需要在第一次计算时算一次之后直接复用。这就是为什么 String 非常适合做HashMap的 key——不但equals语义正确哈希计算也高效。网络安全层面也有体现文件路径、网络地址、类名这类关键字符串如果可变恶意代码可能在你校验完之后、实际使用之前改掉它的内容造成路径穿越或权限绕过。不可变对象天然杜绝了这类检查后修改的攻击窗口。3.3 字符串拼接的性能账为什么循环里不要用 拼接写起来确实顺手String full firstName lastName;。但编译器对这种写法做了什么很多人并不清楚。在编译阶段简单字面量拼接会被直接折叠成常量而涉及变量的拼接编译器会生成new StringBuilder()然后逐个append再toString。单次拼接这样没问题但放到循环里就完全变味了String result ; for (int i 0; i 10000; i) { result result i; // 每次迭代都 new 一个 StringBuilder }每轮循环都会产生一个新的StringBuilder和一个新的 String 对象总共近两万个临时对象。频繁的分配会加大 GC 压力接口一旦并发量上来停顿会非常明显。类似的代码我在实际项目里见过不止一次优化方式通常就是把String换成循环外的StringBuilderStringBuilder sb new StringBuilder(); for (int i 0; i 10000; i) { sb.append(i); } String result sb.toString();JDK 9 之后String的内部存储从char[]换成了byte[]并会根据字符串内容自动选择LATIN1或UTF16两种编码方式英文为主的场景内存占用直接减半。这个 优化对使用方透明知道这回事就行不需要改代码。4. StringBuilder与StringBuffer搞清楚快和安全的取舍再选角4.1 三个兄弟的定位对比String、StringBuilder、StringBuffer都跟字符串相关但各不相同类型可变性线程安全性能典型场景String不可变天然安全拼接大量字符串时最差内容确定的文本、key键StringBuilder可变不安全最快单线程字符串拼接、SQL拼装StringBuffer可变安全方法加锁比 Builder 慢一些多线程共享同一个拼接对象StringBuffer之所以安全是因为它的append等方法用synchronized做了同步。但注意加锁是有代价的——哪怕只有一个线程在操作每次append也要走一遍锁竞争逻辑。这正是实际项目里默认选StringBuilder的原因绝大多数拼接场景都发生在线程内部的局部变量上根本不存在并发问题没必要为永远用不到的安全买单。4.2 StringBuilder的扩容机制和容量参数该不该传StringBuilder底层是一个可变的byte[]JDK 9 之前是char[]。每次append时如果剩余空间不够就会按一定策略扩容新容量大约是旧容量的两倍再加 2然后复制原内容。扩容本身是昂贵的——要申请新数组、拷贝旧数据。如果拼接次数特别多扩容就会反复发生。一个效率优化小技巧是大概率能预估到结果长度时直接传入初始容量StringBuilder sb new StringBuilder(estimatedLength);比如要拼一个可能上万条的批量 SQL 的 IN 条件或生成一段 JSON长度是可以估算的。即使估算偏差一些也远好过从默认 16 开始反复扩容。4.3 何时真的需要考虑用StringBufferStringBuffer并非完全无所作为。假如一个工具方法会被多个线程同时调用且内部持有一个共享的拼接对象StringBuffer能保证append操作的原子性。但说实话这种场景需要仔细想两层如果每个线程都有自己的StringBuilder局部变量那就没必要用StringBuffer。如果多个线程共享同一个拼接对象散落的append即使各自安全拼接结果的顺序也未必是你想要的通常还是需要更大的粒度锁来保证整体顺序。所以一个有点反直觉的结论是StringBuffer的实际适用场景比想象中窄很多。我在代码里见到它多数是在历史遗留代码中。新代码里基本可以不考虑它需要线程安全时优先想清楚并发模型而不是直接上个安全类。5. 日常开发里最容易踩的String陷阱清单5.1 split(.)为什么分不开 IP 地址用split按点分割 IP 是经典翻车现场127.0.0.1.split(.); // 结果数组长度是0原因在于split接收的是正则表达式而.在正则里表示任意字符。正确的写法是split(\\.)或者split(Pattern.quote(.))。不只是点号竖线|、星号*、反斜杠\等正则元字符都有同样的问题。凡是遇到按字符切分不出来的情况优先怀疑正则转义。5.2 replace和replaceAll一字之差语义完全不同replace(CharSequence, CharSequence)处理的是字面量文本而replaceAll(String, String)的第一个参数是正则表达式。于是会出现这类困惑a.b.c.replace(., #); // 结果 a#b#c a.b.c.replaceAll(., #); // 结果 #######因为.匹配任意字符如果只是要替换普通文本优先用replace既免去转义麻烦性能一般也更好。只有确实需要正则能力时才用replaceAll。5.3 equals的调用方向把常量放在前面判断一个字符串是否等于某个固定值时不少人这样写if (input.equals(SUCCESS)) { ... }一旦input是null这里直接抛NullPointerException。更稳妥的是把常量放前面if (SUCCESS.equals(input)) { ... }这样即使input为null也只是返回false不会抛异常。如果你用的是 JDK 7 及以上也可以直接Objects.equals(input, SUCCESS)语义更清晰。这条习惯看起来稀松平常但运行时NPE减少的效果非常立竿见影。5.4 内存视角的substring与intern无意识的隐患substring在旧版 JDK 里有一个著名的问题生成的子字符串会引用原字符串的底层字符数组导致一个很小的子串也会把整个大字符串赖在内存里无法回收。这个问题在 JDK 7 之后的版本里已经调整过底层会做复制但依然值得留意——如果你截取的是一个非常大的文本的很小一段确认一下当前运行版本的实现心里有数总不是坏事。intern()的滥用则要更谨慎它会把字符串加入常量池现代 JVM 里是堆内的字符串池。如果运行时动态生成大量不同内容的字符串并全部intern字符串池可能被撑大最终导致内存压力甚至 GC 压力上升。不是每个程序都需要intern只有当你确定同一个字符串内容会被大量重复引用并且生命周期可控时才值得用它换内存。5.5 空字符串和null两种情况两套处理逻辑和null经常被混为一谈处理方式并不相同。是一个真实对象长度为 0null表示没有引用。判断时需要分流if (str null || str.isEmpty()) { // 常见组合 // 空值处理 }或者用StringUtils.isBlank(str)很多工具库提供会额外把全空格的情况也纳入空白。在实际业务里用户输入的字段往往带有前后空格trim之后再校验空值通常更贴近真实需求。我自己带新人时有一个习惯不要求他们把Object和String的方法倒背如流而是要求他们能在白板上讲清楚这个方法为什么会存在、不实现它会出现什么可见的 bug。比如解释清楚hashCode和equals的契约关系再配合一个HashMap的小实验解释清楚 String 不可变性对常量和缓存的价值再配合循环拼接的性能对比。基础概念一旦落到这些具体场景里就不太容易学了就忘。如果你现在正在学这部分建议写几个小的 demo 类自己把equals、hashCode、toString各重写一遍再把hashCode改成固定值看看HashMap退化成什么样——那种直观感受比看十篇文章都深刻。