Java面试中的“坑”你别踩

1. 基础知识

  • 字符串拼接

    • 🚫 误区：很多人认为使用 + 拼接字符串效率低下，因此完全否定它。但其实，+ 在少量字符串拼接时是完全可行的。然而，如果在循环中频繁拼接字符串，每次拼接都会生成新的字符串对象，这会导致性能问题。此时，应该使用 StringBuilder 或 StringBuffer（线程安全）来优化。

    • 示例“坑”代码：

      String result = "";
for (int i = 0; i < 1000; i++) {
    result += i; // 在循环中使用 + 拼接字符串，效率低下
}

    • 正确姿势：

      StringBuilder sb = new StringBuilder();
for (int i = 0; i < 1000; i++) {
    sb.append(i);
}
String result = sb.toString();

      小贴士：在单线程环境下，优先使用 StringBuilder，因为它比 StringBuffer 更高效。

  • == 和 equals 的区别

    • 🤔 误区：很多人会混淆 == 和 equals 的区别。== 是比较对象的内存地址，而 equals 是比较对象的值（前提是重写了 equals 方法）。对于字符串常量池中的字符串，使用 == 可能会得到 true，但这是特殊情况，不能作为通用规则。

    • 示例“坑”代码：

      String s1 = "Java";
String s2 = "Java";
if (s1 == s2) { // 这里可能返回 true，但不推荐用 == 比较字符串内容
    System.out.println("相同");
}

    • 正确姿势：

      if (s1.equals(s2)) {
    System.out.println("相同");
}

      小贴士：永远使用 equals 比较字符串内容，除非你明确知道字符串来自常量池。

  • 基本数据类型和包装类

    • 🎯 误区：Java 中的基本数据类型和包装类很容易让人混淆。包装类是对象，有默认值（null），而基本数据类型有默认值（如 int 默认为 0）。在自动装箱和拆箱时，如果不小心处理，可能会出现空指针异常。

    • 示例“坑”代码：

      Integer a = null;
int b = a; // 自动拆箱，可能抛出 NullPointerException

    • 正确姿势：

      Integer a = null;
if (a != null) {
    int b = a;
}

      小贴士：尽量避免在可能为 null 的包装类上调用方法或进行拆箱操作。

2. 集合框架

  • HashMap 的线程安全问题

    • 🚧 误区：HashMap 是非常常用的集合，但它不是线程安全的。在多线程环境下，多个线程同时操作 HashMap 可能会导致数据不一致，甚至抛出异常。如果需要线程安全的哈希表，可以使用 ConcurrentHashMap 或对 HashMap 进行同步包装（如 Collections.synchronizedMap）。

    • 示例“坑”代码：

      Map<String, String> map = new HashMap<>();
// 多线程同时操作 map，可能会导致数据丢失或异常

    • 正确姿势：

      Map<String, String> map = new ConcurrentHashMap<>();

      小贴士：ConcurrentHashMap 是线程安全的，且性能优于同步包装的 HashMap。

  • ArrayList 和 LinkedList 的选择

    • 🧐 误区：很多人在选择 ArrayList 和 LinkedList 时会感到困惑。ArrayList 是基于数组实现的，适合随机访问，但插入和删除操作效率较低；而 LinkedList 是基于链表实现的，适合频繁的插入和删除操作。如果不确定具体需求，可以先使用 List 接口，然后根据实际情况选择实现类。

    • 示例“坑”代码：

      List<String> list = new ArrayList<>();
// 如果频繁插入删除，可能会导致性能问题

    • 正确姿势：

      List<String> list = new LinkedList<>();
// 如果需要频繁插入删除，使用 LinkedList 更合适

      小贴士：根据实际需求选择合适的集合类型，不要盲目使用 ArrayList。

3. 多线程

  • 线程安全的误区

    • 🚫 误区：很多人认为使用 synchronized 就可以解决线程安全问题，但实际上，synchronized 只能保证同一时间只有一个线程访问同步代码块。如果同步代码块的范围过大，可能会导致性能问题。另外，锁的粒度越细越好，尽量减少锁的范围。

    • 示例“坑”代码：

      public synchronized void method() {
    // 同步整个方法，可能会导致性能问题
}

    • 正确姿势：

      public void method() {
    synchronized (this) {
        // 只同步需要同步的代码块
    }
}

      小贴士：尽量使用细粒度的锁，避免锁住整个方法。

  • 线程池的使用

    • 🤯 误区：很多人会直接使用 Executors 创建线程池，但这种方式可能会导致线程池的线程数量过多，从而导致 OOM（Out Of Memory）异常。建议使用 ThreadPoolExecutor 自定义线程池，这样可以更好地控制线程池的大小和行为。

    • 示例“坑”代码：

      ExecutorService executor = Executors.newFixedThreadPool(10);

    • 正确姿势：

      ThreadPoolExecutor executor = new ThreadPoolExecutor(
    corePoolSize,
    maximumPoolSize,
    keepAliveTime,
    TimeUnit.SECONDS,
    new LinkedBlockingQueue<Runnable>(queueSize),
    new ThreadPoolExecutor.CallerRunsPolicy()
);

      小贴士：自定义线程池时，合理配置核心线程数、最大线程数、队列大小等参数。

4. 性能优化

  • 过早优化

    • 🤔 误区：很多人喜欢在代码编写阶段就进行优化，但过早优化可能会导致代码复杂度增加，而实际性能提升并不明显。优化应该基于实际的性能问题，而不是凭空猜测。建议先写出清晰易读的代码，然后根据性能测试结果进行优化。

    • 示例“坑”代码：

      // 过早优化，使用复杂的数据结构和算法

    • 正确姿势：

      // 先写出清晰易读的代码，然后根据性能测试结果进行优化

      小贴士：不要为了优化而优化，优化应该基于实际需求。

  • 垃圾回收

    • 🧹 误区：很多人会手动调用 System.gc()，认为这样可以触发垃圾回收。但实际上，垃圾回收是由 JVM 管理的，手动调用可能会导致不必要的性能开销，甚至可能影响 JVM 的垃圾回收策略。

    • 示例“坑”代码：

      System.gc(); // 不推荐手动调用

    • 正确姿势：

      // 交给 JVM 自动管理垃圾回收

      小贴士：不要手动调用 System.gc()，相信 JVM 的垃圾回收机制。

5. 框架和工具

  • Spring 的依赖注入

    • 🚀 误区：在 Spring 中，依赖注入是非常重要的机制。如果直接使用 new 关键字创建对象，那么 Spring 将无法管理该对象，也无法进行依赖注入。这会导致很多问题，比如无法注入其他 Bean。

    • 示例“坑”代码：

      MyService service = new MyService();

    • 正确姿势：

      @Autowired
private MyService service;

      小贴士：尽量使用 Spring 的依赖注入机制，避免直接创建对象。

  • MyBatis 的结果映射

    • 🧐 误区：很多人在使用 MyBatis 时，会忽略结果映射的重要性。如果结果映射不正确，可能会导致查询结果为空或数据不一致。因此，一定要确保结果映射的字段和数据库表中的字段一一对应。

    • 示例“坑”代码：

      <resultMap id="UserResultMap" type="User">
    <result property="id" column="id" />
    <result property="name" column="name" />
    <!-- 缺少某些字段的映射 -->
</resultMap>

    • 正确姿势：

      <resultMap id="UserResultMap" type="User">
    <result property="id" column="id" />
    <result property="name" column="name" />
    <result property="age" column="age" />
    <!-- 确保所有字段都正确映射 -->
</resultMap>

      小贴士：仔细检查 MyBatis 的结果映射，避免遗漏字段。

6. 编码规范

  • 代码可读性

    • 📖 误区：很多人为了追求代码的简洁，会牺牲代码的可读性。但实际上，清晰的代码比复杂的代码更容易维护。建议使用清晰的变量命名、合理的代码结构和适当的注释，让代码更易读。

    • 示例“坑”代码：

      int a=1,b=2,c=3,d=a+b+c;

    • 正确姿势：

      int a = 1;
int b = 2;
int c = 3;
int d = a + b + c;

      小贴士：代码的可读性比简洁性更重要。

  • 注释

    • 📝 误区：很多人会忽略注释的重要性，或者过度注释。注释可以帮助其他开发者更好地理解代码，但也不要过度注释。建议使用清晰的注释来说明代码的逻辑和目的，但不要注释显而易见的内容。

    • 示例“坑”代码：

      // 这是一个方法
public void method() {
    // 这里是方法的实现
}

    • 正确姿势：

      /**
 * 这是一个重要的方法，用于实现核心功能
 */
public void method() {
    // 具体实现逻辑
}

      小贴士：注释要简洁明了，避免冗余。

7. 其他

  • 异常处理

    • 🚫 误区：很多人在捕获异常后，会直接打印异常堆栈，或者忽略异常。这种做法会导致问题难以排查，甚至可能隐藏潜在的错误。

    • 示例“坑”代码：

      try {
    // 可能抛出异常的代码
} catch (Exception e) {
    e.printStackTrace(); // 不推荐直接打印异常堆栈
}

    • 正确姿势：

      try {
    // 可能抛出异常的代码
} catch (Exception e) {
    logger.error("发生异常", e); // 使用日志记录异常
}

      小贴士：使用日志记录异常，方便后续排查问题。

  • 编码格式

    • 📝 误区：很多人会忽略编码格式的重要性。如果项目中文件的编码格式不一致，可能会导致乱码问题。建议统一使用 UTF-8 编码格式。

    • 示例“坑”代码：

      // 文件编码格式不一致，可能导致乱码

      • 正确姿势：

        // 确保项目中所有文件都使用 UTF-8 编码

        小贴士：在项目设置中统一编码格式，避免乱码问题。

posted @   软件职业规划  阅读(8)  评论(0)  编辑  收藏  举报
编辑推荐：
· AI与.NET技术实操系列：基于图像分类模型对图像进行分类
· go语言实现终端里的倒计时
· 如何编写易于单元测试的代码
· 10年+ .NET Coder 心语，封装的思维：从隐藏、稳定开始理解其本质意义
· .NET Core 中如何实现缓存的预热？
阅读排行：
· 分享一个免费、快速、无限量使用的满血 DeepSeek R1 模型，支持深度思考和联网搜索！
· 25岁的心里话
· 基于 Docker 搭建 FRP 内网穿透开源项目（很简单哒）
· ollama系列01：轻松3步本地部署deepseek，普通电脑可用
· 按钮权限的设计及实现
点击右上角即可分享
微信分享提示