思考

牌效率是什么

经营自己的手牌，以达成和牌为目标
我们的任何操作（切牌、碰、吃等）都是为了最终能够和牌服务的，也就是提高和了率。

在只考虑自摸的情况下，我们可以快速的计算出打哪张牌能够使向听数前进、有效牌和改良牌变多。

有效牌

能够减少向听数的牌

通过向听数的计算公式8-2*(面子数)-对子数-搭子数，我们发现，能够减少向听数的牌有以下几
种：

1. 能够与搭子组成一个顺子，此时面子数量+1，搭子数量-1，向听数+1
2. 能够与对子组成一个刻子，此时面子数量+1，对子数量-1，向听数+1
3. 能够与孤张组成一个对子，此时对子数量+1，向听数+1
4. 能够与孤张组成一个搭子，此时搭子数量+1，向听数+1

这样一来就很清晰了，接下来我们来编码，计算以下两种情况

1. 在向听数减少的情况下，打出哪张牌后的有效牌最多
2. 在打出任何牌都不能导致向听数减少的情况下，打出哪张牌后的有效牌最多（也就是指改良）

思考

向听数比较通俗易懂的解释是还差几张牌听牌，用程序能理解的话就是：

1
2

将手牌的n张牌替换成任意一张牌，能够满足听牌的n的最小值
此时，手牌就是n向听

向听数可以由下面的公式快速算出：

1

向听数=8-2x(顺子数量+刻子数量)-对子数量-搭子数量

暂不考虑七对子与国士无双

所以只需要算出顺子、刻子、对子以及搭子的数量即可

但是要注意的是，很多牌形是有多种拆分方式的，诸如下面的示例

1

1234s

可以认为是123的顺子加上孤张4，也可以认为是1的孤张加上234的顺子，还可以认为是12和34两个搭子……

手牌和牌时的组成

日本麻将除了特殊牌形（七对和国士）以外，都是 a个顺子+b个刻子+1个雀头 的形状，这里不管是门清还是非门清，都是这样。其中a、b均大于等于0。

我们可以将手牌分解成上面的形式，如果能够满足条件，则为和牌，然而手牌的组成有很多种，比如下面的手牌（九莲宝灯）：

1

11123455678999s

我们可以分解为

1

111 234 55 678 999

可以和牌

也可以分解为

1

11 123 345 567 8 999

无法和牌

可以看到关键在于怎么对手牌中的顺子和刻子分组
more >>

想法

最近想着爬一个IT技术站，找了JAVA的一些爬虫围观了下，嗯…都不太合心意，还是自制一个吧，参考了 https://github.com/biezhi/elves 的思路，于是就开工了，大约一两周摸鱼的时间，就基本完成了，可以来github围观：https://github.com/chocotan/nekocat
，名字是随便取的。

功能

1. 定时执行
2. 自定义UA、代理池
3. 支持多线程
4. 可自定义Downloader实现headless chrome（大概）
5. 失败重试

成果

于是就找了一些网站开始爬了，注册了个域名，做了个界面，挂上了google adsense

网址：www.codetd.com

最近在瞎折腾rxjava，写了一段自认为能并发执行的代码如下：

1
2
3
4
5
6
7
8
9
10

// 大小为5的线程池
ThreadPoolExecutor exec = new ThreadPoolExecutor(
    5, 5, 200, TimeUnit.SECONDS, new LinkedBlockingQueue<>());

Flowable.just(1, 2, 3, 4, 5)
        .subscribeOn(Schedulers.from(exec))
        .subscribe(i -> {
            Thread.sleep(1000L);
            System.out.println(i + "\t" + Thread.currentThread().getName());
        });

由于我在subscribe中sleep了1s，所以我认为这五个数字会并发的执行到subscribe中去，期待会有如下的输出

1
2
3
4
5

1	pool-1-thread-1
2	pool-1-thread-2
3	pool-1-thread-3
4	pool-1-thread-4
5	pool-1-thread-5

然而事与愿违，实际的输出是这样的

1
2
3
4
5

1	pool-1-thread-1
2	pool-1-thread-1
3	pool-1-thread-1
4	pool-1-thread-1
5	pool-1-thread-1

嗯嗯？为什么没有并发执行subscribe里的代码呢？我以为是我自己的代码有问题，又陆续尝试了内置的一些Scheduler，consumer均是在同一个线程中执行的，好吧，看来是我理解错rxjava的Schedulers了，这货的from方法接收一个Executor参数，并不是指接下来的任务会提交给这个线程池并发的执行。

这大概也是RxJava和CompletableFuture的区别之一吧。搜索了一圈，用rxjava实现并发主要以以下几个方法

1. 在flatMap中使用obseveOn

   1 2 3 4 5 6 7

   Flowable.just(1, 2, 3, 4, 5) .flatMap(i -> Flowable.just(i).observeOn(Schedulers.from(exec)) .doOnNext(d -> { System.out.println(d + "\t" + Thread.currentThread().getName()); Thread.sleep(1000L); })) .subscribe();

2. 在flatMap中使用Future

   1 2 3 4 5 6 7 8

   Flowable.just(1, 2, 3, 4, 5) .flatMap(i -> Flowable.fromFuture(CompletableFuture.completedFuture(i), Schedulers.from(exec)) .doOnNext(d -> { System.out.println(d + "\t" + Thread.currentThread().getName()); Thread.sleep(1000L); }) ) .subscribe();

3. 使用ParallelFlowable

   1 2 3 4 5 6 7 8 9

   Flowable.just(1, 2, 3, 4, 5) .parallel() .runOn(Schedulers.from(exec)) .doOnNext(d -> { System.out.println(d + "\t" + Thread.currentThread().getName()); Thread.sleep(1000L); }) .sequential() .subscribe();

有两个要注意的地方

1. RxJava在执行并发的时候，并不会使用Executor的maximumPollSize这个属性，corePollSize有多大，那么最大就有多少个线程
2. parallel()有一个重载方法可以传入并发数，默认为cpu核心数，在单核的服务器上这个数字是1，也就是不管Executor有多少个线程，只会用一个线程去执行任务

后续

最近发现在使用UnicastProcessor和ParallelFlowable的时候有cpu占用高的情况，经过跟踪发现是这样的问题：

Flowable是支持背压的，所以在元素弹出过快的时候会抛出异常，而我又使用了retry，使得在抛出异常的时候会重新订阅Flowable，而UnicastProcessor只能被订阅一次，所以抛出了大量的IllegalStateException

如题，看上去很不错，于是以后多发技术文

嗯嗯

test123