程序员的成长之路JAVA · ARCHITECTURE · GROWTH

外观

Java业务开发坑点笔记

约 3875 字大约 13 分钟

2024-11-19

学习了极客时间的*Java 业务开发常见错误 100 例*课程，简单摘抄了一些笔记。

并发工具类库类

ThreadLocal类

我们都知道，如果想要保存线程私有的数据，可以使用ThreadLocal类。但是如果程序是运行在Tomcat线程中，由于线程从用，很有可能出现bug。例如以下这个例子：

private static final ThreadLocal<Integer> currentUser = ThreadLocal.withInitial(() -> null);

@GetMapping("wrong")
public Map wrong(@RequestParam("userId") Integer userId) {
    //设置用户信息之前先查询一次ThreadLocal中的用户信息
    String before  = Thread.currentThread().getName() + ":" + currentUser.get();
    //设置用户信息到ThreadLocal
    currentUser.set(userId);
    //设置用户信息之后再查询一次ThreadLocal中的用户信息
    String after  = Thread.currentThread().getName() + ":" + currentUser.get();
    //汇总输出两次查询结果
    Map result = new HashMap();
    result.put("before", before);
    result.put("after", after);
    return result;
}

所以一定要特别关注，程序运行在Tomcat线程中，其实是使用了线程池的，只是对我们屏蔽了线程池的创建。在业务开发中，应该尽量避免我们创建的Component是有状态的，或者需要在程序运行完成后，清理ThreadLocal中的数据。

ConcurrentHashMap只能保证提供的原子性读写操作是线程安全

//线程个数
private static int THREAD_COUNT = 10;
//总元素数量
private static int ITEM_COUNT = 1000;

//帮助方法，用来获得一个指定元素数量模拟数据的ConcurrentHashMap
private ConcurrentHashMap<String, Long> getData(int count) {
    return LongStream.rangeClosed(1, count)
            .boxed()
            .collect(Collectors.toConcurrentMap(i -> UUID.randomUUID().toString(), Function.identity(),
                    (o1, o2) -> o1, ConcurrentHashMap::new));
}

@GetMapping("wrong")
public String wrong() throws InterruptedException {
    ConcurrentHashMap<String, Long> concurrentHashMap = getData(ITEM_COUNT - 100);
    //初始900个元素
    log.info("init size:{}", concurrentHashMap.size());

    ForkJoinPool forkJoinPool = new ForkJoinPool(THREAD_COUNT);
    //使用线程池并发处理逻辑
    forkJoinPool.execute(() -> IntStream.rangeClosed(1, 10).parallel().forEach(i -> {
        //查询还需要补充多少个元素
        int gap = ITEM_COUNT - concurrentHashMap.size();
        log.info("gap size:{}", gap);
        //补充元素
        concurrentHashMap.putAll(getData(gap));
    }));
    //等待所有任务完成
    forkJoinPool.shutdown();
    forkJoinPool.awaitTermination(1, TimeUnit.HOURS);
    //最后元素个数会是1000吗？
    log.info("finish size:{}", concurrentHashMap.size());
    return "OK";
}

ConcurrentHashMap只能保证提供的原子性读写操作是线程安全配图

ConcurrentHashMap 这个篮子本身，可以确保多个工人在装东西进去时，不会相互影响干扰，但无法确保工人 A 看到还需要装 100 个桔子但是还未装的时候，工人 B 就看不到篮子中的桔子数量。更值得注意的是，你往这个篮子装 100 个桔子的操作不是原子性的，在别人看来可能会有一个瞬间篮子里有 964 个桔子，还需要补 36 个桔子。

回到 ConcurrentHashMap，我们需要注意 ConcurrentHashMap 对外提供的方法或能力的限制：

  • 使用了 ConcurrentHashMap，不代表对它的多个操作之间的状态是一致的，是没有其他线程在操作它的，如果需要确保需要手动加锁。
  • 诸如 size、isEmpty 和 containsValue 等聚合方法，在并发情况下可能会反映 ConcurrentHashMap 的中间状态。因此在并发情况下，这些方法的返回值只能用作参考，而不能用于流程控制。显然，利用 size 方法计算差异值，是一个流程控制。
  • 诸如 putAll 这样的聚合方法也不能确保原子性，在 putAll 的过程中去获取数据可能会获取到部分数据。

CopyOnWriteArrayList

CopyOnWriteArrayList 虽然是一个线程安全的 ArrayList，但因为其实现方式是，每次修改数据时都会复制一份数据出来，所以有明显的适用场景，即读多写少或者说希望无锁读的场景。

加锁

加锁前要清楚锁和被保护的对象是不是一个层面的

我们知道静态字段属于类，类级别的锁才能保护；而非静态字段属于类实例，实例级别的锁就可以保护。比如：

class Data {
    @Getter
    private static int counter = 0;

    public static int reset() {
        counter = 0;
        return counter;
    }

    public synchronized void wrong() {
        counter++;
    }
}

测试代码：

@GetMapping("wrong")
public int wrong(@RequestParam(value = "count", defaultValue = "1000000") int count) {
    Data.reset();
    //多线程循环一定次数调用Data类不同实例的wrong方法
    IntStream.rangeClosed(1, count).parallel().forEach(i -> new Data().wrong());
    return Data.getCounter();
}

运行结果：

加锁前要清楚锁和被保护的对象是不是一个层面的配图

在非静态的 wrong 方法上加锁，只能确保多个线程无法执行同一个实例的 wrong 方法，却不能保证不会执行不同实例的 wrong 方法。而静态的 counter 在多个实例中共享，所以必然会出现线程安全问题。

加锁要考虑粒度

  • 无状态的Controller, Service, Resportory等不需要加锁；
  • 加锁可能会极大地降低性能。使用 Spring 框架时，默认情况下 Controller、Service、Repository 是单例的，加上 synchronized 会导致整个程序几乎就只能支持单线程，造成极大的性能问题。

如果精细化考虑了锁应用范围后，性能还无法满足需求的话，我们就要考虑另一个维度的粒度问题了

  • 对于读写比例差异明显的场景，考虑使用 ReentrantReadWriteLock 细化区分读写锁，来提高性能。
  • 如果JDK 版本高于 1.8、共享资源的冲突概率也没那么大的话，考虑使用 StampedLock 的乐观读的特性，进一步提高性能。
  • JDK 里 ReentrantLock 和 ReentrantReadWriteLock 都提供了公平锁的版本，在没有明确需求的情况下不要轻易开启公平锁特性，在任务很轻的情况下开启公平锁可能会让性能下降上百倍。

线程池

《阿里巴巴 Java 开发手册》中提到，禁止使用这些方法来创建线程池，而应该手动 new ThreadPoolExecutor 来创建线程池。这一条规则的背后，是大量血淋淋的生产事故，最典型的就是 newFixedThreadPool 和 newCachedThreadPool，可能因为资源耗尽导致 OOM 问题。

翻看 newFixedThreadPool 方法的源码不难发现，线程池的工作队列直接 new 了一个 LinkedBlockingQueue，而默认构造方法的 LinkedBlockingQueue 是一个 Integer.MAX_VALUE 长度的队列，可以认为是无界的。

翻看 newCachedThreadPool 的源码可以看到，这种线程池的最大线程数是 Integer.MAX_VALUE，可以认为是没有上限的，而其工作队列 SynchronousQueue 是一个没有存储空间的阻塞队列。这意味着，只要有请求到来，就必须找到一条工作线程来处理，如果当前没有空闲的线程就再创建一条新的，会导致创建大量的线程。

不建议使用 Executors 提供的两种快捷的线程池，原因如下：

  • 我们需要根据自己的场景、并发情况来评估线程池的几个核心参数，包括核心线程数、最大线程数、线程回收策略、工作队列的类型，以及拒绝策略，确保线程池的工作行为符合需求，一般都需要设置有界的工作队列和可控的线程数。
  • 任何时候，都应该为自定义线程池指定有意义的名称，以方便排查问题。当出现线程数量暴增、线程死锁、线程占用大量 CPU、线程执行出现异常等问题时，我们往往会抓取线程栈。此时，有意义的线程名称，就可以方便我们定位问题。

Spring声明式事务

事务生效原则

  • 除非特殊配置（比如使用 AspectJ 静态织入实现 AOP），否则只有定义在 public 方法上的 @Transactional 才能生效。原因是，Spring 默认通过动态代理的方式实现 AOP，对目标方法进行增强，private 方法无法代理到，Spring 自然也无法动态增强事务处理逻辑。
  • 必须通过代理过的类从外部调用目标方法才能生效。Spring 通过 AOP 技术对方法进行增强，要调用增强过的方法必然是调用代理后的对象。

事务回滚

  • 只有异常传播出了标记了 @Transactional 注解的方法，事务才能回滚。
  • 默认情况下，出现 RuntimeException（非受检异常）或 Error 的时候，Spring 才会回滚事务。打开 Spring 的 DefaultTransactionAttribute 类能看到如下代码块，可以发现相关证据，通过注释也能看到 Spring 这么做的原因，大概的意思是受检异常一般是业务异常，或者说是类似另一种方法的返回值，出现这样的异常可能业务还能完成，所以不会主动回滚；而 Error 或 RuntimeException 代表了非预期的结果，应该回滚。

事务传播

如果方法涉及多次数据库操作，并希望将它们作为独立的事务进行提交或回滚，那么我们需要考虑进一步细化配置事务传播方式，也就是 @Transactional 注解的 Propagation 属性。

数据库索引

InnoDB 是如何存储数据的

虽然数据保存在磁盘中，但其处理是在内存中进行的。为了减少磁盘随机读取次数，InnoDB 采用页而不是行的粒度来保存数据，即数据被分成若干页，以页为单位保存在磁盘中。InnoDB 的页大小，一般是 16KB。

各个数据页组成一个双向链表，每个数据页中的记录按照主键顺序组成单向链表；每一个数据页中有一个页目录，方便按照主键查询记录。数据页的结构如下：

InnoDB 是如何存储数据的配图

聚簇索引和二级索引

InnoDB 使用 B+ 树建立聚簇索引。B+ 树的特点包括：

  • 最底层的节点叫作叶子节点，用来存放数据；
  • 其他上层节点叫作非叶子节点，仅用来存放目录项，作为索引；
  • 非叶子节点分为不同层次，通过分层来降低每一层的搜索量；
  • 所有节点按照索引键大小排序，构成一个双向链表，加速范围查找。

由于数据在物理上只会保存一份，所以包含实际数据的聚簇索引只能有一个。InnoDB 会自动使用主键（唯一定义一条记录的单个或多个字段）作为聚簇索引的索引键（如果没有主键，就选择第一个不包含 NULL 值的唯一列），如果没有，会隐式创建一个主键列作为索引。

为了实现非主键字段的快速搜索，就引出了二级索引，也叫作非聚簇索引、辅助索引。二级索引，也是利用的 B+ 树的数据结构，如下图所示：

聚簇索引和二级索引配图
这次二级索引的叶子节点中保存的不是实际数据，而是主键，获得主键值后去聚簇索引中获得数据行。这个过程就叫作回表。

创建二级索引的代价，主要表现在维护代价、空间代价和回表代价三个方面。

联合索引匹配

  • 索引 B+ 树中行数据按照索引值排序，只能根据前缀进行比较。
  • 联合索引只能匹配左边的列。在联合索引的情况下，数据是按照索引第一列排序，第一列数据相同时才会按照第二列排序。
  • 条件涉及函数操作无法走索引。索引保存的是索引列的原始值，而不是经过函数计算后的值。

判等问题

注意 equals 和 == 的区别

比较值的内容，除了基本类型只能使用 == 外，其他类型都需要使用 equals。如果基本数据类型使用了装箱操作，由于JVM有缓存，所以两个对象会指向同一个对象。

Integer a = 127; //Integer.valueOf(127)
Integer b = 127; //Integer.valueOf(127)
log.info("\nInteger a = 127;\n" + "Integer b = 127;\n" + "a == b ? {}",a == b); // true

实现equal方法

  • 考虑到性能，可以先进行指针判等，如果对象是同一个那么直接返回 true；
  • 需要对另一方进行判空，空对象和自身进行比较，结果一定是 fasle；
  • 需要判断两个对象的类型，如果类型都不同，那么直接返回 false；
  • 确保类型相同的情况下再进行类型强制转换，然后逐一判断所有字段。

hashCode 和 equals 要配对实现

比如将一个对象放入到HashSet中，我们重写了equal方法，我们再继续new 一个同类型的对象（通过equal方法可以判断为与之前的对象相等），但是我们调用HashSet的equal.contains(obj2)可能会返回false，因为这个方法是通过hashCode去HashSet中寻找的。

浮点数计算

危险的Double

例如：

System.out.println(0.1+0.2);
System.out.println(1.0-0.8);
System.out.println(4.015*100);
System.out.println(123.3/100);

double amount1 = 2.15;
double amount2 = 1.10;
if (amount1 - amount2 == 1.05)
    System.out.println("OK");

输出结果：

0.30000000000000004
0.19999999999999996
401.49999999999994
1.2329999999999999

因为有限小数是无限循环小数，必然会有精度问题，计算机存储有限，无法存储无限循环小数，这是根源。建议使用 BigDecimal 表示和计算浮点数，且务必使用字符串的构造方法来初始化 BigDecimal。

List列表操作

Arrays.asList的坑

  • 不能直接使用 Arrays.asList 来转换基本类型数组，会导致把整个基本类型数组作为一个元素加入到List中。
  • Arrays.asList 返回的 List 不支持增删操作，Arrays.asList 返回的 List 并不是我们期望的 java.util.ArrayList，而是 Arrays 的内部类 ArrayList。ArrayList 内部类继承自 AbstractList 类，并没有覆写父类的 add 方法，而父类中 add 方法的实现，就是抛出 UnsupportedOperationException。
  • ，对原始数组的修改会影响到我们获得的那个 List。看一下 ArrayList 的实现，可以发现 ArrayList 其实是直接使用了原始的数组。所以，我们要特别小心，把通过 Arrays.asList 获得的 List 交给其他方法处理，很容易因为共享了数组，相互修改产生 Bug。

使用合适的List

不要过于迷信教科书的大 O 时间复杂度，对于数组，随机元素访问的时间复杂度是 O(1)，元素插入操作是 O(n)；对于链表，随机元素访问的时间复杂度是 O(n)，元素插入操作是 O(1)。翻看 LinkedList 源码发现，插入操作的时间复杂度是 O(1) 的前提是，你已经有了那个要插入节点的指针。但，在实现的时候，我们需要先通过循环获取到那个节点的 Node，然后再执行插入操作。前者也是有开销的，不可能只考虑插入操作本身的代价。所以，对于插入操作，LinkedList 的时间复杂度其实也是 O(n)。

原文链接: https://juejin.cn/post/7380637950381834278

文章标签