线程安全：既然是线程安全问题，那么毫无疑问，所有的隐患都是在多个线程访问的情况下产生的，也就是我们要确保在多条线程访问的时候，我们的程序还能按照我们预期的行为去执行，我们看一下下面的代码：
Integer count = 0;
public void getCount() {
count ++;
System.out.println(count);
}我开启的3条线程，每个线程循环10次，得到以下结果：
我们可以看到，这里出现了两个26，出现这种情况显然表明这个方法根本就不是线程安全的，出现这种问题的原因有很多。
最常见的一种，就是我们A线程在进入方法后，拿到了count的值，刚把这个值读取出来，还没有改变count的值的时候，结果线程B也进来的，那么导致线程A和线程B拿到的count值是一样的。
那么由此我们可以了解到，这确实不是一个线程安全的类，因为他们都需要操作这个共享的变量。其实要对线程安全问题给出一个明确的定义，还是蛮复杂的，我们根据我们这个程序来总结下什么是线程安全。
当多个线程访问某个方法时，不管你通过怎样的调用方式、或者说这些线程如何交替地执行，我们在主程序中不需要去做任何的同步，这个类的结果行为都是我们设想的正确行为，那么我们就可以说这个类是线程安全的。
搞清楚了什么是线程安全，接下来我们看看Java中确保线程安全最常用的两种方式。先来看段代码。
大家觉得这段代码是线程安全的吗？
毫无疑问，它绝对是线程安全的，我们来分析一下，为什么它是线程安全的？
我们可以看到这段代码是没有任何状态的，就是说我们这段代码，不包含任何的作用域，也没有去引用其他类中的域进行引用，它所执行的作用范围与执行结果只存在它这条线程的局部变量中，并且只能由正在执行的线程进行访问。当前线程的访问，不会对另一个访问同一个方法的线程造成任何的影响。
两个线程同时访问这个方法，因为没有共享的数据，所以他们之间的行为，并不会影响其他线程的操作和结果，所以说无状态的对象，也是线程安全的。
添加一个状态呢？
如果我们给这段代码添加一个状态，添加一个count，来记录这个方法并命中的次数，每请求一次count+1，那么这个时候这个线程还是安全的吗？
public class ThreadDemo {
int count = 0; // 记录方法的命中次数
public void threadMethod(int j) {
count++ ;
int i = 1;
j = j + i;
}
}很明显已经不是了，单线程运行起来确实是没有任何问题的，但是当出现多条线程并发访问这个方法的时候，问题就出现了，我们先来分析下count+1这个操作。
进入这个方法之后首先要读取count的值，然后修改count的值，最后才把这把值赋值给count，总共包含了三步过程：“读取”一>“修改”一>“赋值”，既然这个过程是分步的，那么我们先来看下面这张图，看看你能不能看出问题：
可以发现，count的值并不是正确的结果，当线程A读取到count的值，但是还没有进行修改的时候，线程B已经进来了，然后线程B读取到的还是count为1的值，正因为如此所以我们的count值已经出现了偏差，那么这样的程序放在我们的代码中，是存在很多的隐患的。
springboot中，多线程实现service
首先看一下Dao的实现：
@Repository
@Slf4j
public class UserThreadDao {
@Autowired
private JdbcTemplate jdbcTemplate;
public void add(String username, int threadId, String thread_status) {
String sql = "insert into userthread (username, thread_id, thread_status) values (?,?,?)";
jdbcTemplate.update(sql, new Object[]{username, threadId, thread_status});
log.info("threadId:{}, jdbcTemplate:{}", threadId, jdbcTemplate);
}
public void update(String username, int threadId, String thread_status) {
String sql = "update userthread set thread_status=? where username=? and thread_id=?";
jdbcTemplate.update(sql, new Object[]{thread_status, username, threadId});
}
}
这里的JDBCTemplate是一个线程安全的类，原因是JdbcTemplate使用了ThreadLocal实现，使各线程能够保持各自独立的一个对象，其实就是一个变量副本，实现了线程安全。
因此在这个UserThreadDao中没有共享数据，没有成员变量（JdbcTemplate是线程安全的），因此是线程安全的。
在service中使用多线程来调用dao，代码如下所示：
@Service
@Slf4j
public class UserThreadServiceImpl implements UserThreadService {
@Autowired
UserThreadDao userThreadDao;
@Override
@Async("asyncServiceExecutor")
public void serviceTest(String username) {
log.info("开启执行一个Service, 这个Service执行时间为30s, threadId:{}",Thread.currentThread().getId());
userThreadDao.add(username, Integer.parseInt(Thread.currentThread().getId() +""), "started");
try {
Thread.sleep(30000);
} catch (InterruptedException e) {
e.printStackTrace();
}
log.info("执行完成一个Service, threadId:{}",Thread.currentThread().getId());
userThreadDao.update(username, Integer.parseInt(Thread.currentThread().getId() +""), "ended");
}
}这里的serviceTest方法就是一个多线程方法。线程池的配置如下：
@Configuration
@EnableAsync
@Slf4j
public class ExecutorConfig {
@Autowired
VisiableThreadPoolTaskExecutor visiableThreadPoolTaskExecutor;
@Bean
public Executor asyncServiceExecutor() {
log.info("start asyncServiceExecutor");
ThreadPoolTaskExecutor executor = visiableThreadPoolTaskExecutor;
//配置核心线程数
executor.setCorePoolSize(5);
//配置最大线程数
executor.setMaxPoolSize(5);
//配置队列大小
executor.setQueueCapacity(5);
//配置线程池中的线程的名称前缀
executor.setThreadNamePrefix("async-service-");
// rejection-policy：当pool已经达到max size的时候，如何处理新任务
// CALLER_RUNS：不在新线程中执行任务，而是有调用者所在的线程来执行
executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
//执行初始化
executor.initialize();
return executor;
}
}VisiableThreadPoolTaskExecutor 继承了ThreadPoolTaskExecutor。
详细代码：在https://github.com/vincentduan/mavenProject 下的threadManagement目录下。