Tag: java

一般情况，实现全局唯一ID，有三种方案，分别是通过中间件方式、UUID、雪花算法。

方案一，通过中间件方式，可以是把数据库或者redis缓存作为媒介，从中间件获取ID。这种呢，优点是可以体现全局的递增趋势（优点只能想到这个），缺点呢，倒是一大堆，比如，依赖中间件，假如中间件挂了，就不能提供服务了；依赖中间件的写入和事务，会影响效率；数据量大了的话，你还得考虑部署集群，考虑走代理。这样的话，感觉问题复杂化了

方案二，通过UUID的方式，java.util.UUID就提供了获取UUID的方法，使用UUID来实现全局唯一ID，优点是操作简单，也能实现全局唯一的效果，缺点呢，就是不能体现全局视野的递增趋势；太长了，UUID是32位，有点浪费；最重要的，是插入的效率低，因为呢，我们使用mysql的话，一般都是B+tree的结构来存储索引，假如是数据库自带的那种主键自增，节点满了，会裂变出新的节点，新节点满了，再去裂变新的节点，这样利用率和效率都很高。而UUID是无序的，会造成中间节点的分裂，也会造成不饱和的节点，插入的效率自然就比较低下了。

方案三，基于redis生成全局id策略，因为Redis是单线的天生保证原子性，可以使用原子性操作INCR和INCRBY来实现，注意在Redis集群情况下，同MySQL一样需要设置不同的增长步长，同时key一定要设置有效期，可以使用Redis集群来获取更高的吞吐量

方案四，通过snowflake算法如下：

SnowFlake算法生成id的结果是一个64bit大小的整数，它的结构如下图：

Function

1. Function作为一个函数式接口，主要方法apply接收一个参数，返回一个值

@FunctionalInterface
public interface Function<T, R> {

    /**
     * Applies this function to the given argument.
     *
     * @param t the function argument
     * @return the function result
     */
    R apply(T t);
}

一、前言

最近在翻看中间件源码时候发现有些类实现了AutoCloseable接口，这个接口很生疏，所以搜了下资料，学习了下，下面做个总结。

二、AutoCloseable接口由来

从AutoCloseable的注释可知它的出现是为了更好的管理资源，准确说是资源的释放，当一个资源类实现了该接口close方法，在使用try-catch-resources语法创建的资源抛出异常后，JVM会自动调用close 方法进行资源释放，当没有抛出异常正常退出try-block时候也会调用close方法。像数据库链接类Connection,io类InputStream或OutputStream都直接或者间接实现了该接口。

2.1 使用AutoCloseable之前资源管理方式

如上代码创建了两个资源，在try-catch-finally的finally里面进行手动进行资源释放，释放时候还需要进行catch掉异常，这几乎是经典资源使用的方式，那么既然资源管理都是一个套路，那么为何不做到规范里面那？所以AutoCloseable诞生了。