背景

本来想搭一下 Spring-Boot 组合 Spock 做单元测试，弄了一个很小的 demo 项目测试，结果等到运行的时候 @Resource 注释不生效，bean name 也没错。反而 @Autowired 是能成功注入的，这个真的是奇了怪了。项目大概是这样的：

1
2
3
4
5
6
7
8
9

@SpringBootConfiguration
public class App {
    public static void main(String[] args) {
        ConfigurableApplicationContext applicationContext = SpringApplication.run(App.class, args);
        A a = applicationContext.getBean(A.class);
        B b = a.getB();
        System.out.println(b);
    }
}

分片不宜过大，在故障恢复的时候会更大的影响集群。

The shard is the unit at which Elasticsearch distributes data around the cluster. The speed at which Elasticsearch can move shards around when rebalancing data, e.g. following a failure, will depend on the size and number of shards as well as network and disk performance.

TIP: Avoid having very large shards as this can negatively affect the cluster’s ability to recover from failure. There is no fixed limit on how large shards can be, but a shard size of 50GB is often quoted as a limit that has been seen to work for a variety of use-cases.

ES 只新增数据，不更新数据。更新也只是把旧的数据标记删除，再新增新的数据。被删除的数据在段合并前，是会一直占用资源的。有一种思路是按时间区间将数据分成不同的索引存储，比如 2017 年一份索引、2018 年一份索引。这样索引会更小，每次进入下一个年份都有机会调整分片数量和索引结果，冷数据也可以按年进入归档状态，不会影响在热数据上的业务服务。

去打开 IDEA 的 DEBUG 日志，日志地址在 help - Show log in finder 里，日志配置文件在 /Applications/IntelliJ IDEA.app/Contents/bin/log.xml。启动时的日志有一段明显很值得怀疑：

1
2

2018-05-06 15:34:45,576 [  93768]   INFO - ij.components.ComponentManager - com.seventh7.mybatis.ref.CmProject initialized in 75086 ms
2018-05-06 15:34:45,588 [  93780]   INFO - ellij.project.impl.ProjectImpl - 152 project components initialized in 75849 ms

com.seventh7.mybatis.ref.CmProject 初始化耗了 75 秒。去把 MyBatis 插件禁用以后重新测试：

1

2018-05-06 15:40:13,639 [ 138286]   INFO - ellij.project.impl.ProjectImpl - 150 project components initialized in 999 ms

研究 ForkJoinPool 的时候碰到如下代码：

1
2
3
4
5
6
7
8
9
10

final boolean tryUnpush(ForkJoinTask<?> t) {
    ForkJoinTask<?>[] a; int s;
    if ((a = array) != null && (s = top) != base &&
        U.compareAndSwapObject
        (a, (((a.length - 1) & --s) << ASHIFT) + ABASE, t, null)) {
        U.putOrderedInt(this, QTOP, s);
        return true;
    }
    return false;
}

U.putOrderedInt 这个方法有点迷惑，他和 AtomicInteger 的 lazySet 是一个机制。然后查了些资料：

比较神奇，挖个坑

直接看代码

join

1
2
3
4
5
6
7

public final V join() {
    int s;
    if ((s = doJoin() & DONE_MASK) != NORMAL)
        // 如果没有正常完成去处理异常
        reportException(s);
    return getRawResult();
}

doJoin

1
2
3
4
5
6
7
8
9
10

private int doJoin() {
    int s; Thread t; ForkJoinWorkerThread wt; ForkJoinPool.WorkQueue w;
    // status<0表示任务已经执行完毕
    return (s = status) < 0 ? s :
    ((t = Thread.currentThread()) instanceof ForkJoinWorkerThread) ?
        (w = (wt = (ForkJoinWorkerThread)t).workQueue).
        tryUnpush(this) && (s = doExec()) < 0 ? s :
    wt.pool.awaitJoin(w, this, 0L) :
    externalAwaitDone();
}

文档地址在这里 LongAdder Api

直接看代码

add

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public void add(long x) {
    Cell[] as; long b, v; int m; Cell a;
    // cells非null或者在base上cas递增失败
    if ((as = cells) != null || !casBase(b = base, b + x)) {
        boolean uncontended = true;
        if (as == null || (m = as.length - 1) < 0 ||
            // getProbe()是个随机数，与m求与运算，能获得一个最小0最大m的数
            (a = as[getProbe() & m]) == null ||
            // 利用随机数，去cells上随机取一个Cell做CAS递增
            !(uncontended = a.cas(v = a.value, v + x)))
            // 如果递增失败，即出现竞争，调longAccumulate方法
            longAccumulate(x, null, uncontended);
    }
}

偶然看到的，和 CAS 相关，挖个坑，AtomicReference 里有用到，在 JDK 9 中。

资料

https://docs.oracle.com/javase/9/docs/api/java/lang/invoke/VarHandle.html

已知的 Java 内能保证内存可见性（能做到线程间通信）现在知道大致有这些：

• synchronized 深入理解Java内存模型（五）——锁
• volatile
• Unsafe 内有内存屏障相关的方法，应该也能保证可见性。举个例子 compareAndSwapInt 方法有 volatile 的读和写的内存语义。详细见《Java 内存模型 - 程晓明》「锁内存语义的实现」一节对 ReentrantLock 的分析。（2018 - 03 - 28 更新，另外见 http://www.infoq.com/cn/articles/java-memory-model-5，这个语义是从程晓明的文章中看到的，那么是不是 CAS 变更一个没有用 volatile 申明的变量也是具有 volatile 读和写的语义的？现在看到的代码中一般都是 CAS 去改 volatile 的变量，比如 AQS 中。TODO）
• final 的属性的发布，有点不同，见下面的引用 深入理解Java内存模型（六）——final

先埋个坑

https://github.com/puniverse/quasar
http://docs.paralleluniverse.co/quasar/
http://colobu.com/2016/07/14/Java-Fiber-Quasar/
http://geek.csdn.net/news/detail/71824
http://colobu.com/2016/08/01/talk-about-quasar-again/ （这个哥们的博客写的好，可以看一看）
http://geek.csdn.net/news/detail/71824（写的比较好，Vert.x 中的 vertx-sync 封装了 Quasar，很有意思~~）
https://www.jianshu.com/p/bc7d0d18e89f（vertx-sync）

比较有意思，是一个 Java 的协程实现，可以看看是怎么实现的。

再买几个坑：CompletableFuture、ForkJoinPool