1.初始化Map大小并非用多少指定多少

初始化Map并非用多少初始化Size是多少，建议使用Guava，避免扩容引起的动荡()

说明

如：Map<String, String> map = new HashMap<>(1); 在具体使用时，并非size=1，而是最近的2的幂等，如1实际是2，3实际是4，9实际是16

使用方法

依赖gvaua：Map<String, String> map = Maps.newHashMapWithExpectedSize(7);

<dependency>
  <groupId>com.google.guava</groupId>
  <artifactId>guava</artifactId>
  <version>17.0</version>
</dependency>

手动声明：Map<String, String> map = new HashMap<>(实际存储个数 / 0.75 + 1);

2.线程池初始化严禁使用Executors

使用线程池时候，我们可能会使用下面四个场景，这在alibaba代码规范中都是明令禁止的

// 创建一个单线程化的Executor[因为数量固定，可能会堆积大量请求，导致OOM]
private static ExecutorService singleThreadExecutor = Executors.newSingleThreadExecutor();
// 创建一个固定数目线程的线程池[因为数量固定，可能会堆积大量请求，导致OOM]
private static ExecutorService fixedThreadPool = Executors.newFixedThreadPool(10);
// 创建一个可执行命令的单线程Executor[可能会创建大量的线程，导致OOM]
private static ExecutorService singleThreadScheduledExecutor = Executors.newSingleThreadScheduledExecutor();
// 创建一个可缓存的线程池(60S存活时间)[可能会创建大量的线程，导致OOM]
private static ExecutorService cachedThreadPool = Executors.newCachedThreadPool();

我们先来一个简单的例子，模拟一下使用 Executors 导致 OOM 的情况。

public class ExecutorsDemo {
    private static ExecutorService executor = Executors.newFixedThreadPool(15);
    public static void main(String[] args) {
        for (int i = 0; i < Integer.MAX_VALUE; i++) {
            executor.execute(new SubThread());
        }
    }
}
class SubThread implements Runnable {
    @Override
    public void run() {
        try {
            Thread.sleep(10000);
        } catch (InterruptedException e) {
            //do nothing
        }
    }
}

通过指定 JVM 参数：-Xmx8m -Xms8m 运行以上代码，会抛出 OOM：

Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded 
 at java.util.concurrent.LinkedBlockingQueue.offer(LinkedBlockingQueue.java:416)
 at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1371)
 at com.hollis.ExecutorsDemo.main(ExecutorsDemo.java:16)

以上代码指出，ExecutorsDemo.java 的第 16 行，就是代码中的 executor.execute(new SubThread());。

通过上面的例子，我们知道了 Executors 创建的线程池存在 OOM 的风险，那么到底是什么原因导致的呢？我们需要深入 Executors 的源码来分析一下。其实，在上面的报错信息中，我们是可以看出蛛丝马迹的，在以上的代码中其实已经说了，真正的导致 OOM 的其实是 LinkedBlockingQueue.offer 方法。

Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded
 at java.util.concurrent.LinkedBlockingQueue.offer(LinkedBlockingQueue.java:416)
 at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1371)
 at com.hollis.ExecutorsDemo.main(ExecutorsDemo.java:16)

如果读者翻看代码的话，也可以发现，其实底层确实是通过 LinkedBlockingQueue 实现的：

public static ExecutorService newFixedThreadPool(int nThreads) {
    return new ThreadPoolExecutor(nThreads, nThreads,
                                  0L, TimeUnit.MILLISECONDS,
                                  new LinkedBlockingQueue<Runnable>());
}

如果读者对 Java 中的阻塞队列有所了解的话，看到这里或许就能够明白原因了。Java 中的 BlockingQueue 主要有两种实现，分别是 ArrayBlockingQueue 和 LinkedBlockingQueue。ArrayBlockingQueue 是一个用数组实现的有界阻塞队列，必须设置容量。LinkedBlockingQueue 是一个用链表实现的有界阻塞队列，容量可以选择进行设置，不设置的话，将是一个无边界的阻塞队列，最大长度为 Integer.MAX_VALUE。这里的问题就出在：不设置的话，将是一个无边界的阻塞队列，最大长度为Integer.MAX_VALUE。也就是说，如果我们不设置 LinkedBlockingQueue 的容量的话，其默认容量将会是 Integer.MAX_VALUE。而 newFixedThreadPool 中创建 LinkedBlockingQueue 时，并未指定容量。此时，LinkedBlockingQueue 就是一个无边界队列，对于一个无边界队列来说，是可以不断的向队列中加入任务的，这种情况下就有可能因为任务过多而导致内存溢出问题。上面提到的问题主要体现在 newFixedThreadPool 和 newSingleThreadExecutor 两个工厂方法上，并不是说newCachedThreadPool 和 newScheduledThreadPool 这两个方法就安全了，这两种方式创建的最大线程数可能是Integer.MAX_VALUE，而创建这么多线程，必然就有可能导致 OOM

正确使用：

private static ExecutorService executor = new ThreadPoolExecutor(10, 10, 60L, TimeUnit.SECONDS,
                                                                 new ArrayBlockingQueue(10));

这种情况下，一旦提交的线程数超过当前可用线程数时，就会抛出java.util.concurrent.RejectedExecutionException，这是因为当前线程池使用的队列是有边界队列，队列已经满了便无法继续处理新的请求。但是异常（Exception）总比发生错误（Error）要好。

但是部分alibaba作者更推荐使用guava创建对应的线程池，示例如下：

public class ExecutorsDemo {
    private static ThreadFactory namedThreadFactory = new
            ThreadFactoryBuilder()
            .setNameFormat("demo-pool-%d").build();
    private static ExecutorService pool = new ThreadPoolExecutor(5, 200,
            0L, TimeUnit.MILLISECONDS,
            new LinkedBlockingQueue<Runnable>(1024), namedThreadFactory, new
            ThreadPoolExecutor.
                    AbortPolicy());
    public static void main(String[] args) {
        for (int i = 0; i < Integer.MAX_VALUE; i++) {
            pool.execute(new SubThread());
        }
    }
}

通过上述方式创建线程时，不仅可以避免 OOM 的问题，还可以自定义线程名称，更加方便的出错的时候溯源。

3.Arrays.asList之后不要调用修改操作

String[] str = new String[] { "you", "wu" };
List list = Arrays.asList(str);

因为asList返回的实际是一个Arrays内部类，并没有实现集合的修改方法(add/remove/clear)// 当操作修改方法时，会报UnsupportedOperationException。

第一种情况：list.add("yangguanbao"); 运行时异常。

第二种情况：str[0] = "gujin"; 那么 list.get(0)也会随之修改。[涉及栈堆指针操作，修改数组的数据，导致同样引用该数据的list值被改变]

4.使用 entrySet 遍历 Map 类集合 KV

说明：keySet 其实是遍历了 2 次，一次是转为 Iterator 对象，另一次是从 hashMap 中取出key 所对应的 value。而 entrySet 只是遍历了一次就把 key 和 value 都放到了 entry 中，效率更高。

如果是 JDK8，使用 Map.foreach 方法。

正例：values()返回的是 V 值集合，是一个 list 集合对象；keySet()返回的是 K 值集合，是一个 Set 集合对象；entrySet()返回的是 K-V 值组合集合。

5.SimpleDateFormat不要定义为static

SimpleDateFormat 是线程不安全的类，一般不要定义为 static 变量，如果定义为static，必须加锁，或者使用 DateUtils 工具类。

正例：注意线程安全，使用 DateUtils。亦推荐如下处理：

private static final ThreadLocal<DateFormat> df = new ThreadLocal<DateFormat>() { 
  @Override 
  protected DateFormat initialValue() { 
    return new SimpleDateFormat("yyyy-MM-dd"); 
  } 
};

说明：如果是 JDK8 的应用，可以使用 Instant 代替 Date，LocalDateTime 代替 Calendar，DateTimeFormatter 代替 SimpleDateFormat，官方给出的解释：simple beautiful strong immutable thread-safe。

6.并发修改同一记录时需要加锁

要么在应用层加锁，要么在缓存加锁，要么在数据库层使用乐观锁，使用 version 作为更新依据。

说明：如果每次访问冲突概率小于 20%，推荐使用乐观锁，否则使用悲观锁。乐观锁的重试次数不得小于 3 次

One Trick Per Day

1.初始化Map大小并非用多少指定多少

2.线程池初始化严禁使用Executors

3.Arrays.asList之后不要调用修改操作

4.使用 entrySet 遍历 Map 类集合 KV

5.SimpleDateFormat不要定义为static

6.并发修改同一记录时需要加锁

微服务

热门文章

最新文章

相关电子书