朱彦斌的博客 – 第 3 页 – 记录生活的点滴

296 月 2020

Java延迟初始化的正确方式

by flavorzyb

实例化对象在JVM中实际上包含如下指令：

分配内存空间
初始化对象
将instance指向刚才分配好的内存空间地址

上述步骤在单线程中是没问题的。JVM在指令重排序也不会影响到单线程的执行顺序，但是在多线程环境下就会因为重排序导致出现使用未被初始化完成的对象，指令会被重排序为：

分配内存空间
将instance指向刚分配好的内存空间地址
初始化对象

如果线程1执行到了上述的步骤2，线程2执行就会使用未被初始化完成的对象。

带双重检查的延迟初始化

public class DoubleCheckedInstance {
    private volatile static Instance instance;
    public static Instance getInstance() {
        if (instance == null) {
            synchronized (DoubleCheckedInstance.class) {
                if (instance == null) {
                    instance = new Instance();
                }
            }
        }

        return instance;
    }
}

关键点：

private volatile static Instance instance;

如果没有volatile关键字，则在实例化Instance对象时会出现指令重排序，从而导致在多线程环境下使用了未被初始化完成的对象。

基于类延迟初始化

public class InstanceFactory {
    private static class InstanceHolder {
        public static Instance instance = new Instance();
    }
    
    public static Instance getInstance() {
        return InstanceHolder.instance;
    }
}

JVM在类的初始化阶段（即在Class被加载后，且被线程使用之前），会执行类的初始化。在执行类的初始化期间，JVM会去获取一个锁。这个锁可以同步多个线程对同一个类的初始化。

参考资料：

方腾飞,魏鹏,程晓明.《Java并发编程的艺术》机械工业出版社 ISBN：9787111508243

196 月 2020

docker login无法正常登录

by flavorzyb

在Ubuntu 18.04系统中，在安装有docker-compose时，将无法正常登录。

详情如下：

docker login 
Password: 
Error saving credentials: error storing credentials - err: exit status 1, out: `Cannot autolaunch D-Bus without X11 $DISPLAY`

解决方法，移除掉docker-compose：

sudo apt-get autoremove --purge docker-compose

再执行：

docker login 
Password: 
Login Succeeded

参考：https://github.com/docker/compose/issues/6023

176 月 2020

常见的几种虚拟化方案

by flavorzyb

从大类上分，虚拟化技术可分为基于硬件的虚拟化和基于软件的虚拟化。

其中，真正意义上的基于硬件的虚拟化技术不多见，少数如网卡中的单根多IO虚拟化（Single Root I/OⅤirtualizationand Sharing Specification，SR-IOⅤ）等技术，也超出了本书的讨论范畴。基于软件的虚拟化从对象所在的层次，又可以分为应用虚拟化和平台虚拟化（通常说的虚拟机技术即属于这个范畴）。其中，前者一般指的是一些模拟设备或Wine这样的软件。后者又可以细分为如下几个子类：

完全虚拟化。虚拟机模拟完整的底层硬件环境和特权指令的执行过程，客户操作系统无需进行修改。例如ⅤMware Workstation、ⅤirtualBox、QEMU等。
硬件辅助虚拟化。利用硬件（主要是CPU）辅助支持（目前x86体系结构上可用的硬件辅助虚拟化技术包括Intel-ⅤT和AMD-Ⅴ）处理敏感指令来实现完全虚拟化的功能，客户操作系统无需修改，例如ⅤMware Workstation、Xen、KⅤM。
部分虚拟化。只针对部分硬件资源进行虚拟化，客户操作系统需要进行修改。现在有些虚拟化技术的早期版本仅支持部分虚拟化。
超虚拟化（Paravirtualization）。部分硬件接口以软件的形式提供给客户机操作系统，客户操作系统需要进行修改，例如早期的Xen。
操作系统级虚拟化。内核通过创建多个虚拟的操作系统实例（内核和库）来隔离不同的进程。容器相关技术即在这个范畴。

Docker以及其他容器技术都属于操作系统的虚拟化这个范畴。

Docker和常见的虚拟机方式的差异比较：

Docker和传统的虚拟机方式的不同之处–传统方式是在硬件层面实现虚拟化，需要有额外的虚拟机管理应用和虚拟机操作系统层

174 月 2020

Ubuntu安装tzdata时交互输入问题

by flavorzyb

在制作Ubuntu的Docker镜像时，安装tzdata库会弹出交互提示，中断了镜像文件制作。

解决方法,采用静默安装的方式：

ENV DEBIAN_FRONTEND=non-interactive
RUN apt-get update && apt-get -y install tzdata

134 月 2020

线程池的一种优雅停机的方式

by flavorzyb

如果代码中使用了线程池，一种优雅停机的方式就是注册一个JVM钩子函数，在JVM进程关闭之前，先将线程池关闭，及时释放资源。

public static NamesrvController start(final NamesrvController controller) throws Exception {

        if (null == controller) {
            throw new IllegalArgumentException("NamesrvController is null");
        }

        boolean initResult = controller.initialize();
        if (!initResult) {
            controller.shutdown();
            System.exit(-3);
        }

        Runtime.getRuntime().addShutdownHook(new ShutdownHookThread(log, new Callable<Void>() {
            @Override
            public Void call() throws Exception {
                controller.shutdown();
                return null;
            }
        }));

        controller.start();

        return controller;
    }

link: https://github.com/apache/rocketmq/blob/master/namesrv/src/main/java/org/apache/rocketmq/namesrv/NamesrvStartup.java

134 月 2020

RocketMQ笔记

by flavorzyb

1. RocketMQ消息写入磁盘的方式：同步刷盘和异步刷盘

❑ 异步刷盘方式：在返回写成功状态时，消息可能只是被写入了内存的PAGECACHE，写操作的返回快，吞吐量大；当内存里的消息量积累到一定程度时，统一触发写磁盘动作，快速写入。

❑ 同步刷盘方式：在返回写成功状态时，消息已经被写入磁盘。具体流程是，消息写入内存的PAGECACHE后，立刻通知刷盘线程刷盘，然后等待刷盘完成，刷盘线程执行完成后唤醒等待的线程，返回消息写成功的状态。

同步刷盘还是异步刷盘，是通过Broker配置文件里的flushDiskType参数设置的，这个参数被配置成SYNC_FLUSH、ASYNC_FLUSH中的一个。

2. RocketMQ主从同步方式：同步复制和异步复制

如果一个Broker组有Master和Slave，消息需要从Master复制到Slave上，有同步和异步两种复制方式。

同步复制方式是等Master和Slave均写成功后才反馈给客户端写成功状态；

异步复制方式是只要Master写成功即可反馈给客户端写成功状态。

这两种复制方式各有优劣，在异步复制方式下，系统拥有较低的延迟和较高的吞吐量，但是如果Master出了故障，有些数据因为没有被写入Slave，有可能会丢失；在同步复制方式下，如果Master出故障，Slave上有全部的备份数据，容易恢复，但是同步复制会增大数据写入延迟，降低系统吞吐量。

同步复制和异步复制是通过Broker配置文件里的brokerRole参数进行设置的，这个参数可以被设置成ASYNC_MASTER、SYNC_MASTER、SLAVE三个值中的一个。

实际应用中要结合业务场景，合理设置刷盘方式和主从复制方式，尤其是SYNC_FLUSH方式，由于频繁地触发磁盘写动作，会明显降低性能。

通常情况下，应该把Master和Save配置成ASYNC_FLUSH的刷盘方式，主从之间配置成SYNC_MASTER的复制方式，这样即使有一台机器出故障，仍然能保证数据不丢，是个不错的选择。

3. 部分顺序消息

要保证部分消息有序，需要发送端和消费端配合处理。在发送端，要做到把同一业务ID的消息发送到同一个Message Queue；在消费过程中，要做到从同一个Message Queue读取的消息不被并发处理，这样才能达到部分有序。

4. 消息的Tag和Key

对一个应用来说，尽可能只用一个Topic，不同的消息子类型用Tag来标识（每条消息只能有一个Tag），服务器端基于Tag进行过滤，并不需要读取消息体的内容，所以效率很高。发送消息设置了Tag以后，消费方在订阅消息时，才可以利用Tag在Broker端做消息过滤。

其次是消息的Key。对发送的消息设置好Key，以后可以根据这个Key来查找消息。所以这个Key一般用消息在业务层面的唯一标识码来表示，这样后续查询消息异常，消息丢失等都很方便。Broker会创建专门的索引文件，来存储Key到消息的映射，由于是哈希索引，应尽量使Key唯一，避免潜在的哈希冲突。

Tag和Key的主要差别是使用场景不同，Tag用在Consumer的代码中，用来进行服务端消息过滤，Key主要用于通过命令行查询消息。

5. Consumer的负载均衡

DefaultMQPushConsumer的负载均衡

DefaultMQPushConsumer的负载均衡过程不需要使用者操心，客户端程序会自动处理，每个DefaultMQPushConsumer启动后，会马上会触发一个doRebalance动作；而且在同一个ConsumerGroup里加入新的DefaultMQPushConsumer时，各个Consumer都会被触发doRebalance动作。

以AllocateMessageQueueAveragely策略为例，如果创建Topic的时候，把Message Queue数设为3，当Consumer数量为2的时候，有一个Consumer需要处理Topic三分之二的消息，另一个处理三分之一的消息；当Consumer数量为4的时候，有一个Consumer无法收到消息，其他3个Consumer各处理Topic三分之一的消息。可见Message Queue数量设置过小不利于做负载均衡，通常情况下，应把一个Topic的Message Queue数设置为16。

DefaultMQPullConsumer的负载均衡

Pull Consumer可以看到所有的Message Queue，而且从哪个Message Queue读取消息，读消息时的Offset都由使用者控制，使用者可以实现任何特殊方式的负载均衡。

DefaultMQPullConsumer有两个辅助方法可以帮助实现负载均衡，一个是registerMessageQueueListener函数，registerMessageQueueListener函数在有新的Consumer加入或退出时被触发。另一个辅助工具是MQPullConsumerScheduleService类，使用这个Class类似使用DefaultMQPushConsumer，但是它把Pull消息的主动性留给了使用者。

6. 配置文件

Property Name	Default value	Details
listenPort	10911	listen port for client
namesrvAddr	null	name server address
brokerIP1	InetAddress for network interface	Should be configured if having multiple addresses
brokerName	null	broker name
brokerClusterName	DefaultCluster	this broker belongs to which cluster
brokerId	0	broker id, 0 means master, positive integers mean slave
storePathCommitLog	$HOME/store/commitlog/	file path for commit log
storePathConsumerQueue	$HOME/store/consumequeue/	file path for consume queue
mapedFileSizeCommitLog	1024 * 1024 * 1024(1G)	mapped file size for commit log
deleteWhen	04	When to delete the commitlog which is out of the reserve time
fileReserverdTime	72	The number of hours to keep a commitlog before deleting it
brokerRole	ASYNC_MASTER	SYNC_MASTER/ASYNC_MASTER/SLAVE
flushDiskType	ASYNC_FLUSH	{SYNC_FLUSH/ASYNC_FLUSH}. Broker of SYNC_FLUSH mode flushes each message onto disk before acknowledging producer. Broker of ASYNC_FLUSH mode, on the other hand, takes advantage of group-committing, achieving better performance.