Alwayswithme's Blog

分布式锁

Fri, 09 Jun 2017 09:44:22 +0000

在分布式系统中，如多个实例或集群节点中，要有一种方式来保证同步共享资源的访问。此时编程语言提供的锁同步便无能为力，这时就需要用到分布式锁。分布式锁常用于：

保证计算效率：通过锁互斥避免消耗大量资源的重复计算，具体场景：防止并发请求
保证数据一致：保证同一份数据每次只有一个进程修改，具体场景：下单减库存

思路

简单来说可以分为三步操作

获取锁，此时有可能获取失败可加入重试或阻塞逻辑
执行具体操作
释放锁，此时要判断可能存在超时自动释放的逻辑

实现方式

根据系统架构和技术栈的不同，实现方式可以分为：

数据库的乐观锁或排它锁

乐观锁一般是指增加一个版本号，修改数据时每次都会更新版本号，保证只有一次修改。排它锁，利用 SELECT ... FROM ... FOR UPDATE 的语法选择一行数据上排他锁，其他事务在执行这条语句会阻塞。另外，可以把数据库引擎改为 InnoDB 并用上唯一索引将锁优化为行锁。

缓存的原子性操作

MemCache 的 ADD 命令，这个命令的作用是只有 key 不存在时才添加，可以认为获得了锁。 Redis 的 SET 也类似，没有看错，Redis 2.6.12 之后的版本 SET 命令可以添加 NX 选项来替代 SETNX 。鉴于大量资料还是用 SETNX, GETSET 等命令组合来检查时间戳加锁，这里有必要提一下。两种方式分别在两个 Redis 命令文档的下面可以查阅。

新的实现方式 SET 配合 Lua 脚本：https://redis.io/commands/set
旧的实现方式 SETNX, GET 和 GETSET: https://redis.io/commands/setnx

ZooKeeper 临时节点

基于 ZooKeeper 创建临时有序节点，锁可以认为是由创建最小序号的节点进程获取，释放锁删除创建的有序临时节点即可。

利用 MemCache 和 Spring AOP 的简单实现

先写一个简单的类，这个类是无状态的，很适合作为Spring 的 Bean。可以看作是一个 LockService

public class MemCacheLock {

	private MemCachedClient client;

	public MemCacheLock(MemCachedClient client) {
		this.client = client;
	}

	/**
	 * 通过 add(lockKey, token) 获取锁
	 *
	 * @param lockKey 上锁的 key
	 * @param retry 重试次数
	 * @param expireSec 过期时间，单位秒
	 * @param token key 对应的 value, 删除时比对避免释放其他客户端的锁
	 * @return
	 */
	public boolean acquire(String lockKey, int retry, int expireSec, String token) {
		// anyMatch 迭代 retry + 1 次，直到成功获取锁
		return IntStream.rangeClosed(0, retry).anyMatch((i) -> {
			// 第一次获取锁不等待，随后的重试等待 100 ms
			try {
				TimeUnit.MILLISECONDS.sleep(i > 0 ? 100 : 0);
			} catch (InterruptedException e) {
				e.printStackTrace();
			}
			return client.add(lockKey, token, new Date(expireSec * 1000));
		});
	}

	/**
	 * 通过 del(lockKey) 释放锁
	 *
	 * @param lockKey 上锁的 key
	 * @param token key 对应的 value
	 * @return
	 */
	public boolean release(String lockKey, String token) {
		Object obj = client.get(lockKey);
		String get = "";
		if (obj instanceof String) {
			get = (String) obj;
		}
		// 通过 token 保证不会释放其他客户端的锁
		return Objects.equals(get, token) && client.delete(lockKey);
	}
}

因为 acquire 和 release 总是配合使用，可以利用模板方法在切面里应用，定义一个 annotation 和 aspect

@Target({ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface DistributedLock {

	/**
	 * 省略 default 要显示指定一个key
	 */
	String key();

	int expired() default 10;

	int acquireRetry() default 3;
}

@Aspect
@Component
public class DistributedLockAspect {

	@Autowired
	MemCacheLock lockService;

	@Around("@annotation(distributedLock)")
	public Object runWithLock(ProceedingJoinPoint pjp, DistributedLock distributedLock) throws Throwable {
		int expired = distributedLock.expired();
		int retry = distributedLock.acquireRetry();
		String key = "dist_lock_" + distributedLock.key();

		long l = (System.currentTimeMillis() / 1000) + Thread.currentThread().hashCode();
		String token = String.valueOf(l);

		boolean acquired = false;
		try {
			acquired = lockService.acquire(key, retry, expired, token);
			if (acquired) {
				return pjp.proceed();
			}
		} finally {
			if (acquired) {
				lockService.release(key, token);
			}
		}

		throw new RuntimeException("can not acquire lock");
	}
}

随后在 service 和 dao 方法中，标注上 @DistributedLock(key="test") 便能上锁，但是要注意这里如果无法获取锁会抛出异常

Redlock

Redis 官方提出的一种分布式锁算法 Redlock，但可以在文档的最后看到有一些有意思的讨论，分析 Redlock 是否靠谱。

https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html
http://antirez.com/news/101

其他更健壮的实现

Redisson: 可以作为 Redis Java 客户端，提供了分布式锁和和同步器，API非常友好，中文 Wiki 也非常完善
Curator: 一个更高层抽象的 ZooKeeper 客户端，其中的 InterProcessMutex 便是分布式锁

译：Inside NGINX: How We Designed for Performance & Scale

Tue, 16 May 2017 21:16:49 +0000

NGINX 的官方博客有不少高质量的文章，其中一篇高屋建瓴的介绍了 NGINX 的架构。NGINX 的设计使用了 Reactor 模式, 下面提到的 master 和 worker 即所谓的 MainReactor 和 SubReactor, 意会即可。

原文链接：Inside NGINX: How We Designed for Performance & Scale

深入 NGINX: 性能与拓展

NGINX 能在 web 性能上独树一帜归功于它软件的设计方式。鉴于大部分 web 服务器和应用服务器使用简单线程/进程架构, 精致的事件驱动模型使得 NGINX 脱颖而出, 令它能在现代的硬件上处理成千上万的并发连接。

这份 Inside NGINX 信息图从高级的进程架构切入, 描述 NGINX 是如何以单一进程处理多个连接。本文更详细地解释它是如何工作的。

好戏开场, NGINX 进程模型

了解 NGINX 是如何运行的将有助于你更好理解这个设计。 NGINX 有一个 master 进程(负责执行像读取配置和绑定端口这样的权限操作) 和一系列 worker 进程和 helper 进程。

# service nginx restart
* Restarting nginx
# ps -ef --forest | grep nginx
root     32475     1  0 13:36 ?        00:00:00 nginx: master process /usr/sbin/nginx \
                                                -c /etc/nginx/nginx.conf
nginx    32476 32475  0 13:36 ?        00:00:00  \_ nginx: worker process
nginx    32477 32475  0 13:36 ?        00:00:00  \_ nginx: worker process
nginx    32479 32475  0 13:36 ?        00:00:00  \_ nginx: worker process
nginx    32480 32475  0 13:36 ?        00:00:00  \_ nginx: worker process
nginx    32481 32475  0 13:36 ?        00:00:00  \_ nginx: cache manager process
nginx    32482 32475  0 13:36 ?        00:00:00  \_ nginx: cache loader process

在这台四核服务器， NGINX 的 master 进程创建了四个 worker 进程和一系列缓存 helper 进程负责管理磁盘上的内容缓存。

为什么架构很重要？

一切 Unix 程序的基本单元都是线程和进程。(从 Linux 操作系统来说, 线程和进程是大体相似的；主要区别在于它们共享内存的程度。) 一个线程或进程是一组由 CPU 调度在一个核芯上运行的独立指令集。大部分复杂的程序并行运行多个线程或进程，原因有二：

可以同时使用更多计算核芯
可以让并行操作简单的进行(举例来说，同时处理多个连接)。

进程和线程会消耗资源。它们都要用到内存和其他操作系统资源，而且调度时需要在核芯中装入和移出(一种叫上下文切换的操作)。多数现代的服务器可以同时处理数百个的小型，活跃的线程和进程，不过一旦内存用尽或者 I/O 负载很高导致大量的上下文切换性能将严重下降。

网络程序的常用设计方式是为每一个连接分配一个线程或进程。这种架构很简单而且方便实现, 但难以拓展至处理成千上万的连接。

译注: C10K 问题

NGINX 工作方式

NGINX 使用一种可预测的进程模型，并为可用硬件资源进行优化:

master 进程执行诸如读取配置和绑定端口等权限操作, 然后创建少量的子进程(下面介绍的三种类型)。
cache loader 进程在启动时把磁盘缓存载入内存, 然后退出。它被谨慎的调度所以资源需求很低。
cache manager 进程周期性的运行并清理磁盘缓存条目, 使其保持在配置指定的大小。
worker 进程负责其余工作, 包括处理网络连接, 磁盘内容读写, 和上游服务器通讯。

大多数情况下 NGINX 推荐配置为一个核芯一个 worker 进程，这样可以最高效利用硬件资源。可以在配置文件的 worker_processes 指令中设置一个 auto 参数来启用。

worker_processes auto;

NGINX 启动后, 只有 worker 进程是忙碌的。每个 worker 进程以非阻塞的方式处理多个连接, 减少上下文切换的次数。

每个 worker 进程是单线程且独立运行的，拿到新的连接并进行处理。进程间可以使用共享内存来共用缓存数据，会话持久数据还有其他共享资源。

深入 NGINX Worker 进程

NGINX worker 进程使用 NGINX 配置进行初始化, 并获取一组由 master 进程提供的监听套接字。

NGINX worker 进程首先等待监听套接字上的事件(accept_mutex和kernel socket sharding)。新接入的连接触发事件。连接分配到一个状态机，最常用的是 HTTP 状态机，但 NGINX 也为原生TCP流和一系列邮件协议(SMTP, IMAP 和 POP3)实现了状态机。

状态机本质上是告诉 NGINX 如何处理请求的指令集。大部分 web 服务器也是像 NGINX 一样使用状态机来提供这样的功能，但内部实现不同。

译注: 通过设置 accept_mutex 以串行化的方式唤醒一个 worker, 避免惊群。设置 reuseport(就是上面提到的 kernel socket sharding 特性) 后每个 worker 持有一个socket由内核决定哪个 worker 获得连接。

状态机的调度

把状态机想像为国际象棋规则。每个 HTTP 事务都是一次国际象棋对局。棋盘的一边是 web 服务器，可以快速作出决定的象棋大师。另一边是远程客户端，通过相对慢速的网络访问网页或应用的浏览器。

然而，游戏规则可能非常复杂。例如 web 服务器可能还需要和第三方通信(代理到上游)或和认证服务器交互。服务器上的第三方模块甚至可以拓展游戏规则。

阻塞的状态机

回想前面对于进程和线程的描述，它们是操作系统可以在一个核芯上调度运行的一组指令集。大多数 web 服务器和 web 应用使用每个连接一个进程或每个连接一个线程的模型来下象棋。每个进程或线程都包含从头到尾进行下棋的指令。服务器运行过程中，耗费了大量的时间等待客户端采取进一步行动，即“阻塞”。

web 服务器进程在监听新来的连接(客户端触发开局)。 2. 新的一局开始后，进程走了一步后就会阻塞以等待客户端响应。
一旦对局结束， web 服务器进程还可能等待让客户端新开一局游戏(对应于 keepalive 连接)。如果连接关闭(客户端离开或发生超时), 进程又回到监听状态。

重点要记住每个活跃的 HTTP 连接(每次国际象棋对局)都要求一个专门的进程或线程(一个棋手)。这种架构可以简单方便地进行第三方模块拓展(新规则)。但是存在极大的不平衡：由文件描述符和少量内存表示的相对轻量级的 HTTP 连接影射为一个单独的非常重量级的操作系统对象线程或进程。这方便了编程却极大地浪费了资源。

NGINX 是真正的大师

你或许听说过车轮战吧？一个国际象棋大师同时和几十个对手下棋。

这就是 NGINX worker 进程“下棋”的方式。每个 worker (记住,通常是每个核芯一个 worker) 都是一个可以同时进行上百场(事实上，成千上万)对局的棋手。

worker 等待监听和连接的套接字触发事件。
worker 处理套接字上发生的事件：
- 监听套接字上的事件意味着客户端开始了新的对局。worker 创建一个新的连接套接字。
- 连接套接字上的事件意味着客户端走了一步。worker 适当的应对。

Worker 从不在网络通讯上阻塞来等待它的“对手”(客户端)响应。当它走了一步后，worker 立即处理其他需要处理的对局或迎接新来的对手。

比阻塞式多进程的架构更快的原因

NGINX 可以很好地扩展，以支持每个工作进程成千上万的连接。每个新连接在 worker 进程中创建另一个文件描述符和消耗少量的内存。每个连接几乎没有额外的开销。NGINX进程可以保持在 CPU 中运行。上下文切换相对不频繁仅在进程没有更多工作需要完成时进行。

在阻塞式每进程一个连接的方式中，每个连接需要大量的额外资源和开销还有上下文切换(进程在CPU中交换)非常频繁。

进一步的解释可以查看这篇关于 NGINX 架构的文章, 由 NGINX 的企业发展副总裁和联合创始人 Andrew Alexeev 所写。

加上适当的系统调优, NGINX 可以扩展至每个 worker 进程处理数十万个并发HTTP连接并可以吸收流量尖峰（新对局的涌入），而毫不乱套。

NGINX 配置更新和升级

NGINX 这种使用少量 worker 进程的架构可以极其有效的更新配置文件乃至 NGINX 二进制执行文件本身.

更新 NGINX 配置是容易、轻量和可靠的操作。一般是通过运行 nginx -s reload 命令，它会检查磁盘中的配置并给 master 进程发送 SIGHUP 信号。

当 master 进程接收 SIGHUP, 它做了两件事情:

加载配置并 fork 一组新的 worker 进程。这些 worker 进程马上开始接收新连接和处理网络请求（使用新的配置）。
发送信号让旧的 worker 优雅退出。这些 worker 进程停止接收新连接。只要每个现有的 HTTP 请求完成， worker 进程干净地关闭连接(换句话说，就是没有活动的连接)。当旧 worker 进程所有连接完全关闭后便会退出。

重新加载配置的过程会造成 CPU 和内存使用率少量上升, 但和活跃连接加载资源相比这一般不易察觉。你可以每秒多次更新配置(很多 NGINX 用户确实这么做)。少数情况下，当很多代 NGINX worker 进程等待连接关闭时会出现问题，但即使是这样也会很快解决。

NGINX的二进制升级过程实现了高可用性，你可以随时升级，而不导致任何连接丢失，停机时间或服务中断。

二进制升级过程和优雅地重新加载配置的方式类似。新的 master 进程和原来的 master 进程并行运行，共享监听的 socket。两个进程都是活动的，它们有相应的 worker 进程处理通讯。你可以给旧的 master 和它的 worker 进程发信号让它优雅退出。

更多关于整个过程的描述在控制 NGINX。

结论

Inside NGINX 信息图提供对 NGINX 如何运作的高级概述，不过这简单的说明背后是逾十年的革新和优化。这使得 NGINX 在各种硬件上提供最佳性能的同时保持现代 web 应用程序所需的安全性和可靠性。

如果你希望了解更多关于 NGINX 优化，请查看这些资源:

Installing and Tuning NGINX for Performance (webinar; slides at Speaker Deck)
Tuning NGINX for Performance
The Architecture of Open Source Applications – NGINX
Socket Sharding in NGINX Release 1.9.1 (using the SO_REUSEPORT socket option)

改造匿名内部类

Sat, 08 Apr 2017 13:32:54 +0000

最近接手的项目中，看到一个分页对象用了一种奇怪的实现方式。一个 Paging 接口定义了获取分页大小和页码的方法，后续的查询竟然每次都通过匿名内部类去实现这个接口，然后作为查询参数。

示例代码

public interface Paging {
    int getSize();
    int getCurrentPage();
}

public class Test {
    public static void main(String[] args) {
        Paging paging = new Paging() {
            @Override
            public int getSize() {
                return 10;
            }

            @Override
            public int getCurrentPage() {
                return args.length;
            }
        };

        // 使用 paging 计算limit offset做分页查询
    }
}

对这段代码不爽的地方

冗长，可读性和维护性差
编译出来会多几个形如 xxx$1.class 文件

每个匿名内部类都要加载、链接、初始化虽然对现代JVM影响不大，但加载类过多还是有可能导致JDK7及以前版本的 PernGem OOM 和JDK8 Metaspace OOM。

改造方式

本质就是一个实现了 Paging 接口 data class 就能解决，IDEA 也提供相应的重构方法。先转为内部类，在抽到其他地方统一修改。

右键匿名类 -> Refactor -> Convert Anonymous to Inner
右键内部类 -> Refactor -> Move

最终类文件变成

class MyPaging implements Paging {
    private final String[] args;

    public MyPaging(String[] args) {
        this.args = args;
    }

    @Override
    public int getSize() {
        return 10;
    }

    @Override
    public int getCurrentPage() {
        return args.length;
    }
}

感觉还是比较呆，再稍加修改，主要参考 MyBatis 的 RowBounds。除此之外，Spring Data 的 Pageable 及其实现类也是很优雅的分页实现。

public class MyPaging implements Paging {

    public static final int DEFAULT_SIZE = 10;
    public static final int DEFAULT_PAGE = 1;
    public static final MyPaging DEFAULT = new MyPaging(DEFAULT_SIZE, DEFAULT_PAGE);
    
    private int size;
    private int currentPage;
    
    public static MyPaging defaultPaging() {
        return DEFAULT;
    }

    public MyPaging(int s, int p) {
        this.size = s;
        this.currentPage = p;
    }

    @Override
    public int getSize() {
        return this.size;
    }

    @Override
    public int getCurrentPage() {
        return this.currentPage;
    }
}

现在通过两个参数创建MyPaging对象就可以了

其他思考

匿名内部类主要是方便，但不利于复用，而且导致很多class文件。像Runable，Comparator这样只有一个抽象方法要实现的接口(由此也多了一个@FunctionalInterface的注解)， Java 8 的lambda表达式感觉更优雅。

public class Anonymous {
    public static void main(String[] args) {
        Comparator<String> cmp1 = new Comparator<String>() {
            @Override
            public int compare(String o1, String o2) {
                return 1;
            }
        };

        Comparator<String> cmp2 = new Comparator<String>() {
            @Override
            public int compare(String o1, String o2) {
                return 1;
            }
        };
    }
}

像上面这段代码最终会生成三个类文件，哪怕两个匿名内部类完全一致。这时可以改为Lambda表达式，使代码更简洁优雅。

两张图对比，还可以得出的结论

Lambda 表达式不是匿名类的语法糖，有自己的实现方式
匿名类最终编译的文件比 Lambda 大，674 B + 812 B + 812 B > 1.4 KB

最后补充

回到主题，项目里各处用到这个 Paging 都是这种匿名内部类的写法，也不知道生产环境存在多少class文件。按照我上面的对比代码，把 Comparator 增加至10个，每个xxx$1..10.class都占812 B，难怪搭建环境时 Tomcat 的老是出现 PernGem OOM，但也和大量 JSP 和 Servlet 有关。

最近看了很多JD，很有感觉的一段话是：

我们希望你对互联网或J2EE应用开发的最新潮流有关注，喜欢去看及尝试最新的技术，追求编写优雅的代码，从技术趋势和思路上能影响技术团队

也终于理解为什么《The Pragmatic Programmer》和《Refactoring: Improving the Design of Existing Code》会多次强调 DRY 原则的重要性

使用Optional

Fri, 10 Mar 2017 21:26:42 +0000

Java 8 引入了一个新的类java.util.Optinal来处理null引用，熟悉 Guava 的人应该对这个不陌生， Guava 的文档开篇就是介绍这个东西。
Guava 的 Optional 作用有限，一般用来作为方法的返回值如Optional<T>，表示可能缺失T，迫使调用者做对应处理。但 Java 的 Optional 可以配合方法引用和函数接口做更多的事情。类似还有 Guava 的 Joiner 和 Java 8 的 StringJoiner。

Optional 结构比较简单，可以看作成员变量value的容器。

public final class Optional<T> {
    /**
     * Common instance for {@code empty()}.
     */
    private static final Optional<?> EMPTY = new Optional<>();

    /**
     * If non-null, the value; if null, indicates no value is present
     */
    private final T value;

    // ...省略其他代码
}

构造方法

Optional 的构造方法私有，通过三个静态工厂方法构造。

Optional<String> empty = Optional.empty();  // 没有值的Optinal，返回静态变量EMPTY
Optional<String> present = Optional.of("str"); // 包含非空值的Optional

String maybeNullStr = null;
Optional<String> absent = Optional.ofNullable(maybeNullStr); // 内部会判断，如果为空返回empty，不为空返回包含值的Optinal

orElse, orElseGet

如果值不存在，返回默认值。参数需要提供一个默认值，其中orElse直接提供，orElseGet则通过函数接口提供。

String arg = null;
System.out.println(arg == null ? "default value" : arg);

Optional<String> argOpt = Optional.ofNullable(arg);
System.out.println(argOpt.orElse("default value"));
System.out.println(argOpt.orElseGet(() -> "default value"));

orElseThrow

针对值不存在，抛出异常的情况，可以通过orElseThrow方便地做到。

if (arg == null) {
    throw new IllegalArgumentException();
}

// 方法引用不能传参
argOpt.orElseThrow(IllegalArgumentException::new);
// 如果需要message，可以用 lambda 表达式
argOpt.orElseThrow(() -> new IllegalArgumentException("must not null"));

isPresent, ifPresent

前者判断Optinal的值是否存在，然后通过get取出。后者提供一个函数，值存在则将其消费。

Optional<String> value = Optional.of("value");
if (value.isPresent()) {
    value.get();
}

value.ifPresent(System.out::println);

map, flatMap

map要提供一个转换函数，转换后再通过Optional.ofNullable()返回

public<U> Optional<U> map(Function<? super T, ? extends U> mapper) {
    Objects.requireNonNull(mapper);
    if (!isPresent())
        return empty();
    else {
        return Optional.ofNullable(mapper.apply(value));
    }
}

flatMap与map类似，但转换函数的返回值必须为Optional，转换后不会再包装Optional以避免生成多重Optional。

public<U> Optional<U> flatMap(Function<? super T, Optional<U>> mapper) {
    Objects.requireNonNull(mapper);
    if (!isPresent())
        return empty();
    else {
        return Objects.requireNonNull(mapper.apply(value));
    }
}

注意事项

声明为Optional的字段或返回值不可为null，缺失值要用Optional.empty()代替，缺失值要用Optional.empty()代替，缺失值要用Optional.empty()代替，不然还是会导致NullPointerException。只要Optional不为null，它的API就可以安全的调用。类似于Null Object的设计模式。

Optional<String> optional = null;
optional.isPresent();   // NPE

多线程模拟抓牌

Sun, 05 Mar 2017 11:00:39 +0000

鹅厂笔试题

请模拟斗地主抓牌，扑克牌的值为１～５４，随机选取地主，并从地主开始按顺序抓牌，直到牌剩余三张。要求，用线程模拟玩家抓牌。

思路

用三个线程表示玩家，三个线程编号。对剩余的牌数取模计算顺序，编号和顺序相同时，开始抓牌。否则等待。线程重复执行，直到每个线程拿到的牌数等于１７。

完整代码

省略了随机选地主的过程，用 Lock 和 Condition 来进行线程同步。放到线程池执行，主线程调用 shutdown() 等待线程池的任务执行完。

public class CardPlayer implements Runnable {

    private ReentrantLock lock;
    private Condition takeCard;

    private List<Integer> holdCard;
    private List<Integer> cardStack;
    private int order;
    private String name;

    public CardPlayer(ReentrantLock lock, Condition takeCard, List<Integer> cardStack, int order, String name) {
        this.lock = lock;
        this.takeCard = takeCard;
        this.cardStack = cardStack;
        this.order = order;
        this.name = name;
        this.holdCard = new ArrayList<>(17);
    }

    @Override
    public void run() {
        lock.lock();
        try {
            while (holdCard.size() < 17) {
                while ((54 - cardStack.size()) % 3 != order) {
                    takeCard.await();
                }
                Integer card = cardStack.remove(0);
                holdCard.add(card);
                System.out.println(String.format("%-4s 拿到牌 %02d", name, card));
                takeCard.signalAll();
            }
            takeCard.signalAll();
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            lock.unlock();
        }
    }

    public static void main(String[] args) throws InterruptedException {
        List<Integer> cardStack = IntStream.rangeClosed(1, 54).boxed().collect(Collectors.toList());
//        Collections.shuffle(list);

        ReentrantLock lock = new ReentrantLock();
        Condition takeCard = lock.newCondition();
        CardPlayer p1 = new CardPlayer(lock, takeCard, cardStack, 0, "地主");
        CardPlayer p2 = new CardPlayer(lock, takeCard, cardStack, 1, "农民1");
        CardPlayer p3 = new CardPlayer(lock, takeCard, cardStack, 2, "农民2");

        ExecutorService executorService = Executors.newFixedThreadPool(3);
        executorService.execute(p1);
        executorService.execute(p2);
        executorService.execute(p3);

        executorService.shutdown();
    }
}

BCrypt 加密

Mon, 27 Feb 2017 09:38:18 +0000

采用MD5或SHA-2家族的不可逆哈希函数混淆密码，由于它们被设计用来快速的计算数据的摘要值，通常是不可靠的。随着计算机性能的提高和GPU并行运算优化等手段可以越来越快的计算，降低了暴力破解的难度。
BCrypt是一种专门的密码散列函数，在1999年首次发布，各种语言都已有相应实现。它通过引入一个工作因子（work factor）以对抗摩尔定律，随着计算能力的提高，也可以相应的加大这个因子提高暴破成本。而且由于计算时间较慢和难以让GPU有效的计算，可以使安全级别大大提高。因此被称为 A Future-Adaptable Password Scheme 。

BCrypt 格式

加密字符串一般类似于$2a$10$7QDYxuYJBCEKu1q8IMHYg.3lq6OTiA5seEjtnYGOccsC0MkLtvJrS，可以分为四个部分

$<id>$<cost>$<salt><digest>

<id> 表示哈希算法和格式, 一到两个字符
<cost> 04 ~ 31, 工作因子，要重复迭代2**cost次，两个字符
<salt> 128位表示的盐，使用特殊的Base64编码为22个字符
<digest> 最终的结果值，184位编码为31个字符

3(美元符号) + 1 or 2 + 2 + 22 + 34 = 59 or 60

所以总长比较固定，数据库可以采用CHAR(60)，且无需其他字段存储盐

使用示例

示例中用到的BCrypt由Spring Security提供

public class PasswordHashTest {

    private final String plainPasswd = "1234@abcd";

    @Test
    public void normalTest() {
        String hash1 = BCrypt.hashpw(plainPasswd, BCrypt.gensalt());
        Assert.assertTrue(BCrypt.checkpw(plainPasswd, hash1));
    }

    @Test
    public void strongerTest() {
        // 通常这个测试会跑比较久，计算能力过剩可改为BCrypt.gensalt(31)
        String hash2 = BCrypt.hashpw(plainPasswd, BCrypt.gensalt(14));
        Assert.assertTrue(BCrypt.checkpw(plainPasswd, hash2));
    }
}

JDBC 的代码简化

Tue, 21 Feb 2017 11:01:53 +0000

很多JDBC的教程和博文还在用较旧的方式来访问数据库。
利用 Java 6 的 JDBC 4.0 API 和 Java 7 的 try-with-resources 语法可以大大简化冗长的代码。

Java 7 以前的写法

可以看到有很多资源清理的操作，也要手动装载 JDBC 驱动

    private static final String URL = "jdbc:mysql://localhost";
    private static final String USER = "root";
    private static final String PASSWD = "secret";
    private static final String STATEMENT = "SHOW DATABASES";
    
    public static void priorJava7JDBC() {
        Connection conn = null;
        Statement stmt = null;
        ResultSet rs = null;
        try {
            Class.forName("com.mysql.jdbc.Driver");  // 注册驱动

            conn = DriverManager.getConnection(URL, USER, PASSWD); // 打开连接

            stmt = conn.createStatement();
            rs = stmt.executeQuery(STATEMENT);  // 执行语句

            // 处理结果
            while (rs.next()) {
                System.out.println(rs.getString("Database"));
            }
            // 资源清理
            rs.close();
            stmt.close();
            conn.close();
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            closeQuietly(rs);
            closeQuietly(stmt);
            closeQuietly(conn);
        }
    }

    public static void closeQuietly(AutoCloseable closeable) {
        try {
            if(closeable != null) {
                closeable.close();
            }
        } catch (Exception e) {
        }
    }

Java 7 之后的写法

通过try-with-resources 省略了资源清理的代码，类似与 Python 的 with 语法，也无需注册驱动

    public static void afterJava7JDBC() {
        try (Connection connection = DriverManager.getConnection(URL, USER, PASSWD);
             PreparedStatement stmt = connection.prepareStatement(STATEMENT)) {
            try (ResultSet rs = stmt.executeQuery()) {

                while(rs.next()) {
                    System.out.println(rs.getString("Database"));
                }
            }
        } catch (SQLException e) {
            e.printStackTrace();
        }
    }

try-with-resources 异常处理方式

try-with-resources 可以理解为自动调用 close 方法的语法糖，但异常处理有差异，看下面的例子

static String readFirstLineFromFileWithFinallyBlock(String path)
                                                     throws IOException {
    BufferedReader br = new BufferedReader(new FileReader(path));
    try {
        return br.readLine();
    } finally {
        if (br != null) br.close();
    }
}

static String readFirstLineFromFile(String path) throws IOException {
    try (BufferedReader br =
                   new BufferedReader(new FileReader(path))) {
        return br.readLine();
    }
}

readFirstLineFromFileWithFinallyBlock方法如果 readLine 和 close 同时抛出异常，方法的异常会是 finally 语句块的异常。try 语句块的异常被suppressed。相比之下，readFirstLineFromFile方法如果 readLine 和 try-with-resources 调 close 方法都抛出异常，方法的异常会是 try 语句块的异常，即 readLine 的异常， try-with-resources 的异常被suppressed。可以通过抛出的异常调用 Throwable.getSuppressed 方法获得 try-with-resources 的异常。

原文描述如下：

However, in this example, if the methods readLine and close both throw exceptions, then the method readFirstLineFromFileWithFinallyBlock throws the exception thrown from the finally block; the exception thrown from the try block is suppressed. In contrast, in the example readFirstLineFromFile, if exceptions are thrown from both the try block and the try-with-resources statement, then the method readFirstLineFromFile throws the exception thrown from the try block; the exception thrown from the try-with-resources block is suppressed. In Java SE 7 and later, you can retrieve suppressed exceptions; see the section Suppressed Exceptions for more information.

还可以更简便吗

上面的代码虽然有一定程度简化，但还是需要打开连接、执行语句、遍历结果集等操作，通过 Spring 的 JdbcTemplate 配合 Java 8 的流式api以及lambda表达式可以让代码变得更加简洁，接近One-Liners。例如：

jdbcTemplate.query(
        "SELECT id, first_name, last_name FROM customers WHERE first_name = ?", new Object[] { "Josh" },
        (rs, rowNum) -> new Customer(rs.getLong("id"), rs.getString("first_name"), rs.getString("last_name"))
).forEach(customer -> log.info(customer.toString()));

具体可看教程

Shadowsocks 翻墙

Sun, 19 Feb 2017 09:54:53 +0000

记录在 VPS 搭建 shadowsocks 翻墙全过程

准备 VPS

选择 DigitalOcean 作为 VPS：

稳定性不错
有途径获得35刀免费试用7个月
kvm 虚拟化，支持调节内核参数

如何获得35美元？

通过推广链接注册
绑定信用卡或用paypal激活账户,获得10刀
注册Codeanywhere帐号
注册好后依次点击File -> New Connection -> Digital Ocean, 点击Get Coupon
获得优惠后在DigitalOcean的Billing界面填入, 再获得25刀

安装 shadowsocks-libev

~ # dnf copr enable librehat/shadowsocks
~ # dnf update
~ # dnf install shadowsocks-libev

编辑服务器端配置文件 /etc/shadowsocks-libev/config.json

{
    "server":"0.0.0.0",
    "server_port":10718,
    "local_port":1080,
    "password":"passwd",
    "timeout":800,
    "method":"chacha20",
    "fast_open":true,     // 需要内核 3.7+
    "mode": "tcp_and_udp"
}

systemctl enable shadowsocks-libev.service   # 开机自启动
systemctl start shadowsocks-libev.service    # 运行ss-server

修改内核参数

编辑/etc/sysctl.conf

# max open files
fs.file-max = 51200
# max read buffer
net.core.rmem_max = 67108864
# max write buffer
net.core.wmem_max = 67108864
# default read buffer
net.core.rmem_default = 65536
# default write buffer
net.core.wmem_default = 65536
# max processor input queue
net.core.netdev_max_backlog = 4096
# max backlog
net.core.somaxconn = 4096

# resist SYN flood attacks
net.ipv4.tcp_syncookies = 1
# reuse timewait sockets when safe
net.ipv4.tcp_tw_reuse = 1
# turn off fast timewait sockets recycling
net.ipv4.tcp_tw_recycle = 0
# short FIN timeout
net.ipv4.tcp_fin_timeout = 30
# short keepalive time
net.ipv4.tcp_keepalive_time = 1200
# outbound port range
net.ipv4.ip_local_port_range = 10000 65000
# max SYN backlog
net.ipv4.tcp_max_syn_backlog = 4096
# max timewait sockets held by system simultaneously
net.ipv4.tcp_max_tw_buckets = 5000
# turn on TCP Fast Open on both client and server side
net.ipv4.tcp_fastopen = 3
# TCP receive buffer
net.ipv4.tcp_rmem = 4096 87380 67108864
# TCP write buffer
net.ipv4.tcp_wmem = 4096 65536 67108864
# turn on path MTU discovery
net.ipv4.tcp_mtu_probing = 1

# require linux kernel 4.9
net.core.default_qdisc=fq
# for high-latency network
net.ipv4.tcp_congestion_control =bbr

# for strongswan vpn
net.ipv4.ip_forward = 1

然后执行

sysctl -p

MongoDB 笔记

Wed, 07 Sep 2016 16:54:18 +0000

MongoDB 使用备忘

备份`mongodump`

# 备份整个数据库并压缩为 gzip 包到指定路径
mongodump --archive=/tmp/mongodb.gz --db test --gzip --host <host>:<port>
# 备份整个数据库并压缩为 gzip 包到标准输入
mongodump --archive --db test --gzip --host <host>:<port>

恢复`mongorestore`

# 从 gzip 压缩包中恢复，加 `--drop` 恢复前把旧数据 drop 掉
mongorestore --archive=/tmp/mongodb.gz --gzip --db test --drop
# 利用管道机制从标准输入中恢复数据库，相当于远程导入本地
mongodump --archive --db test  --host <remoteip> --gzip| mongorestore --archive --host localhost --drop --gzip

ArchLinux 搭建安卓开发环境

Wed, 12 Aug 2015 21:33:10 +0000

Android-Studio 和相关 SDK 直接从包管理器 yaourt 下载，让系统中所有用户都能使用

准备

64位系统， Pacman 先开启 multilib 需要用到相关的包
为了让 Android-Studio 字体美观，安装 infinality-bundle 和打过 infinality 补丁的 jdk8-openjdk-infinality

配置

安装 Yaourt

用 yaourt 安装软件包时需要打包，开启 xz 的多线程压缩加快打包过程开启方法: 编辑 /etc/makepkg.conf 修改其中一项

# /etc/makepkg.conf

[...]
COMPRESSXZ=(xz -T 0 -c -z -)
[...]

减少与 yaourt 的交互

# 复制配置文件
cp /etc/yaourtrc ~/.yaourtrc

# 编辑文件取消下列两项的注释并修改值
BUILD_NOCONFIRM=1
EDITFILES=0

翻墙

aur 中部分包下载也需要翻墙，使用 Shadowsocks 只需在终端通过修改环境变量让 yaourt 走代理

export http_proxy=socks5://127.0.0.1:1080 https_proxy=socks5://127.0.0.1:1080

需要安装的包

yaourt -S aur/android-bash-completion \
aur/android-google-apis \
aur/android-google-apis-x86 \
aur/android-google-repository \
aur/android-platform \
aur/android-sdk \
aur/android-sdk-build-tools \
aur/android-sdk-platform-tools \
aur/android-sources \
aur/android-studio \
aur/android-support \
aur/android-support-repository

陷入漫长等待

Android-Studio 初始启动

让 /opt/android-sdk/ 对 sudoer 可写

chown -R :wheel /opt/android-sdk/
chmod -R g+w /opt/android-sdk/

打开 Android-Studio ，初始启动，选 custom 将 sdk 下载目录改为 /opt/android-sdk/，再返回选择 standard ，一直 next 直到 finish. 随便创建一个项目，还要下载 gradle ，再次陷入漫长等待。

模拟器硬件加速

安装 kvm 相关的包

sudo pacman -S qemu libvirt

给模拟器添加相关的选项 see also

Alwayswithme's Blog

分布式锁

思路

实现方式

数据库的乐观锁或排它锁

缓存的原子性操作

ZooKeeper 临时节点

利用 MemCache 和 Spring AOP 的简单实现

Redlock

其他更健壮的实现

相关链接

译：Inside NGINX: How We Designed for Performance & Scale

深入 NGINX: 性能与拓展

好戏开场, NGINX 进程模型

为什么架构很重要？

NGINX 工作方式

深入 NGINX Worker 进程

状态机的调度

阻塞的状态机

NGINX 是真正的大师

比阻塞式多进程的架构更快的原因

NGINX 配置更新和升级

结论

改造匿名内部类

示例代码

改造方式

其他思考

最后补充

使用Optional

构造方法

orElse, orElseGet

orElseThrow

isPresent, ifPresent

map, flatMap

注意事项

See Also

多线程模拟抓牌

鹅厂笔试题

思路

完整代码

BCrypt 加密

BCrypt 格式

使用示例

See Also

JDBC 的代码简化

Java 7 以前的写法

Java 7 之后的写法

try-with-resources 异常处理方式

还可以更简便吗

See Also

Shadowsocks 翻墙

准备 VPS

如何获得35美元？

安装 shadowsocks-libev

修改内核参数

MongoDB 笔记

备份mongodump

恢复mongorestore

ArchLinux 搭建安卓开发环境

准备

配置

安装 Yaourt

翻墙

需要安装的包

Android-Studio 初始启动

模拟器硬件加速

备份`mongodump`

恢复`mongorestore`