JAVA 程序员分级,你属于哪一种?

  • 初级 — 初

掌握 java 基础,熟悉常用类库。理解 java web 中的 servlet,jsp,并了解常用的框架对 java web 的封装原理,能够借助框架完成增删改查功能。理解数据库在 web 开发中的地位。

  • 初级 — 中

    理解 java 中较为高级的特性,如反射,动态代理,JVM,内存模型,多线程等等。熟练使用框架,对框架中遇到的 bug,能够借助日志和搜索引擎分析出问题的原因。在团队中,能够独立完成普通后台业务功能的开发。了解数据库的高级特性,如索引,存储引擎等等。


java 并发实践 --ConcurrentHashMap 与 CAS

前言

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

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

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

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


volatile 疑问记录

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

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


浅析 java 内存模型(JMM)

并发编程模型的分类

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

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

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

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


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


java trick--String.intern()

《深入理解 java 虚拟机》第二版中对 String.intern() 方法的讲解中所举的例子非常有意思

不了解 String.intern() 的朋友要理解他其实也很容易,它返回的是一个字符串在字符串常亮池中的引用。直接看下面的 demo

1
2
3
4
5
6
7
8
9
10
11
public class Main {
public static void main(String[] args) {
String str1 = new StringBuilder("计算机").append("软件").toString();
System.out.println(str1.intern() == str1);

<!-- more -->

String str2 = new StringBuilder("ja").append("va").toString();
System.out.println(str2.intern() == str2);
}
}

两者输出的结果如下:

1
2
true
false

我用的 jdk 版本为 Oracle JDK7u45。简单来说,就是一个很奇怪的现象,为什么 java 这个字符串在类加载之前就已经加载到常量池了?

我在知乎找到了具体的说明,如下:

1
2
3
4
5
6
7
8
9
10
11
package sun.misc;

import java.io.PrintStream;

public class Version {
private static final String launcher_name = "java";
private static final String java_version = "1.7.0_79";
private static final String java_runtime_name = "Java(TM) SE Runtime Environment";
private static final String java_runtime_version = "1.7.0_79-b15";
...
}

而 HotSpot JVM 的实现会在类加载时先调用:

1
2
3
4
5
6
7
8
9
public final class System{
...
private static void initializeSystemClass() {
...
sun.misc.Version.init();
...
}
...
}

原来是 sun.misc.Version 这个类在起作用。


java trick -- intergerCache

看一段代码:

1
2
3
4
5
6
7
public class Main {
public static void main(String[] args) {
Integer a=100,b=100,c=150,d=150;
System.out.println(a==b);
System.out.println(c==d);
}
}

这段代码会输出什么?


Your browser is out-of-date!

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

×