前言

被群里的好友安利了一发，周日跑去参加了一个技术讲座《云上开发与运维最佳实践》，听完两个人的演讲之后才发现主题竟然是讲运维，好在有一个人干货不少，在此记录下所得。简单追溯了一下这个 DevOps 才发现并不是一个新的概念，早在 2010 年就能看到有相关的人在追捧这个概念了。DevOps 就是开发（Development）和运维（Operations）这两个领域的合并。（如果没错的话，DevOps 还包括产品管理、QA、winces 甚至销售等领域）。这种理念和现如今流行的微服务架构以及分布式特性的相关理念不谋而合。这篇文章主要就是转载记录了当时又拍云运维总监的演讲稿。

DevOps 的八荣八耻

前言

最近在做接口限流时涉及到了一个有意思问题，牵扯出了关于 concurrentHashMap 的一些用法，以及 CAS 的一些概念。限流算法很多，我主要就以最简单的计数器法来做引。先抽象化一下需求：统计每个接口访问的次数。一个接口对应一个 url，也就是一个字符串，每调用一次对其进行加一处理。可能出现的问题主要有三个：

1. 多线程访问，需要选择合适的并发容器
2. 分布式下多个实例统计接口流量需要共享内存
3. 流量统计应该尽可能不损耗服务器性能

但这次的博客并不是想描述怎么去实现接口限流，而是主要想描述一下遇到的问题，所以，第二点暂时不考虑，即不使用 redis。

说到并发的字符串统计，立即让人联想到的数据结构便是 ConcurrentHashpMap<String,Long> urlCounter;

对 java 中 volatile 关键字的描述，主要是 可见性 和 有序性 两方面。

一个很广泛的应用就是使得多个线程对共享资源的改动变得互相可见，如下：

并发编程模型的分类

在并发编程中，我们需要处理两个关键问题：线程之间如何通信及线程之间如何同步（这里的线程是指并发执行的活动实体）。通信是指线程之间以何种机制来交换信息。在命令式编程中，线程之间的通信机制有两种：共享内存和消息传递。

在共享内存的并发模型里，线程之间共享程序的公共状态，线程之间通过写 - 读内存中的公共状态来隐式进行通信。在消息传递的并发模型里，线程之间没有公共状态，线程之间必须通过明确的发送消息来显式进行通信。

同步是指程序用于控制不同线程之间操作发生相对顺序的机制。在共享内存并发模型里，同步是显式进行的。程序员必须显式指定某个方法或某段代码需要在线程之间互斥执行。在消息传递的并发模型里，由于消息的发送必须在消息的接收之前，因此同步是隐式进行的。

Java 的并发采用的是共享内存模型，Java 线程之间的通信总是隐式进行，整个通信过程对程序员完全透明。如果编写多线程程序的 Java 程序员不理解隐式进行的线程之间通信的工作机制，很可能会遇到各种奇怪的内存可见性问题。

前言

控制并发的方法很多，我之前的两篇博客都有过介绍，从最基础的 synchronized，juc 中的 lock，到数据库的行级锁，乐观锁，悲观锁，再到中间件级别的 redis，zookeeper 分布式锁。今天主要想讲的主题是“根据并发出现的具体业务场景，使用合理的控制并发手段”。

什么是并发

由一个大家都了解的例子引入我们今天的主题：并发

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

public class Demo1 {

    public Integer count = 0;

    public static void main(String[] args) {
        final Demo1 demo1 = new Demo1();
        Executor executor = Executors.newFixedThreadPool(10);
        for(int i=0;i<1000;i++){
            executor.execute(new Runnable() {
                @Override
                public void run() {
                    demo1.count++;
                }
            });
        }
        try {
            Thread.sleep(5000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        System.out.println("final count value:"+demo1.count);
    }
}

console:
final count value:973

这个过程中，类变量 count 就是共享资源，而 ++ 操作并不是线程安全的，而多个线程去对 count 执行 ++ 操作，并没有 happens-before 原则保障执行的先后顺序，导致了最终结果并不是想要的 1000

前言

回首大三下的暑假，那时候刚开始出来找实习，如今已经即将进入大四下学期，恍惚间，已经过去了 8，9 个月。写这篇文章的初衷就是想结合自己的经验给即将要出来找工作的应届生一些建议，想当初自己刚出来时，也得到过热心学长的教导，权当一种传递吧。

服务组件化

组件，是一个可以独立更换和升级的单元。就像 PC 中的 CPU、内存、显卡、硬盘一样，独立且可以更换升级而不影响其他单元。

在“微服务”架构中，需要我们对服务进行组件化分解。服务，是一种进程外的组件，它通过 http 等通信协议进行协作，而不是传统组件以嵌入的方式协同工作。服务都独立开发、部署，可以有效的避免一个服务的修改引起整个系统的重新部署。

打一个不恰当的比喻，如果我们的 PC 组件以服务的方式构建，我们只维护主板和一些必要外设之后，计算能力通过一组外部服务实现，我们只需要告诉 PC 我们从哪个地址来获得计算能力，通过服务定义的计算接口来实现我们使用过程中的计算需求，从而实现 CPU 组件的服务化。这样我们原本复杂的 PC 服务得到了更轻量化的实现，我们甚至只需要更换服务地址就能升级我们 PC 的计算能力。

SimpleDateFormat 众所周知是线程不安全的，多线程中如何保证线程安全又同时兼顾性能问题呢？那就是使用 ThreadLocal 维护 SimpleDateFormat

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

public class SimpleDateFormatThreadTest {

    static volatile AtomicInteger n = new AtomicInteger(-1);

<!-- more -->

    static ThreadLocal<DateFormat> sdf ;

    static {
        sdf =new ThreadLocal<DateFormat>() {
            @Override
            protected DateFormat initialValue() {
                return new SimpleDateFormat("yyyy-MM-dd");
            }
        };
    }

    public static void main(String[] args) throws ParseException, InterruptedException {

        Set<String> dateSet = new ConcurrentHashSet<>();
        Set<Integer> numberSet = new ConcurrentHashSet<>();

        Date[] dates = new Date[1000];
        for (int i = 0; i < 1000; i++) {
            dates[i] = sdf.get().parse(i + 1000 + "-11-22");
        }

        ExecutorService executorService = Executors.newFixedThreadPool(10);
        for(int i=0;i<1000;i++){
            executorService.execute(new Runnable() {
                @Override
                public void run() {
                    int number = n.incrementAndGet();
                    String date = sdf.get().format(dates[number]);
                    numberSet.add(number);
                    dateSet.add(date);
                    System.out.println(number+" "+date);
                }
            });
        }
        executorService.shutdown();
        Thread.sleep(5000);
        System.out.println(dateSet.size());
        System.out.println(numberSet.size());
    }

}

实践证明 sdf 的 parse（String to Date）有严重的线程安全问题，format（Date to String）有轻微的线程安全问题，虽然不太明显，但还是会出现问题，这和内部的实现有关。

简单分析下使用 ThreadLocal 的好处，1000 次转换操作，10 个线程争抢执行，如果每次都去 new 一个 sdf，可见其效率之低，而使用 ThreadLocal，是对每个线程维护一个 sdf，所以最多就只会出现 10 个 sdf，真正项目中，由于操作系统线程分片执行，所以线程不会非常的多，使用 ThreadLocal 的好处也就立竿见影了。

@Transactional 可以说是 spring 中最常用的注解之一了，通常情况下我们在需要对一个 service 方法添加事务时，加上这个注解，如果发生 unchecked exception，就会发生 rollback，最典型的例子如下。

时下很多企业应用更新换代到分布式，一篇文章了解什么是 RPC。
原作者梁飞，在此记录下他非常简洁的 rpc 实现思路。