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 次
