java 并发实践 --ConcurrentHashMap 与 CAS

前言

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

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

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

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


volatile 疑问记录

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

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


浅析项目中的并发

前言

控制并发的方法很多,我之前的两篇博客都有过介绍,从最基础的 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


ThreadLocal 的最佳实践

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 的好处也就立竿见影了。


使用 JPA 实现乐观锁

乐观锁的概念就不再赘述了,不了解的朋友请自行百度谷歌之,今天主要说的是在项目中如何使用乐观锁,做成一个小 demo。

持久层使用 jpa 时,默认提供了一个注解 @Version 先看看源码怎么描述这个注解的

1
2
3
4
@Target({METHOD, FIELD})
@Retention(RUNTIME)
public @interface Version {
}

简单来说就是用一个 version 字段来充当乐观锁的作用。
先来设计实体类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
/**
* Created by xujingfeng on 2017/1/30.
*/
@Entity
@Table(name = "t_student")
public class Student {

@Id
@GenericGenerator(name = "PKUUID", strategy = "uuid2")
@GeneratedValue(generator = "PKUUID")
@Column(length = 36)
private String id;

@Version
private int version;

private String name;

//getter()...
//setter()...
}

Your browser is out-of-date!

Update your browser to view this website correctly.&npsb;Update my browser now

×