Java高并发之从零到放弃

简介: 本篇主要讲解如何去优化锁机制或者克服多线程因为锁可导致性能下降的问题

前言
本篇主要讲解如何去优化锁机制
或者克服多线程因为锁可导致性能下降的问题
ThreadLocal线程变量
有这样一个场景,前面是一大桶水,10个人去喝水,为了保证线程安全,我们要在杯子上加锁
导致大家轮着排队喝水,因为加了锁的杯子是同步的,只能有一个人拿着这个唯一的杯子喝水
这样子大家都喝完一杯水需要很长的时间
如果我们给每个人分发一个杯子呢?是不是每人喝到水的时间缩小到了十分之一
多线程并发也是一个道理
在每个Thread中都有自己的数据存放空间(ThreadLocalMap)
而ThreadLocal就是在当前线程的存放空间中存放数据
下面这个例子,在每个线程中存放一个arraylist,而不是大家去公用一个arraylist

public class ThreadLocalTest {
    public static ThreadLocal threadLocal = new ThreadLocal();
    public static ArrayList list = new ArrayList();
    public static class Demo implements Runnable {
        private int i;
        public Demo(int i) {
            this.i = i;
        }
        @Override
        public void run() {
            list.add(i);
            threadLocal.set(list);
            System.out.println(threadLocal.get());
        }
    }
    public static void main(String[] args) throws InterruptedException {
        ExecutorService es = Executors.newFixedThreadPool(5);
        for (int j = 0; j < 200; j++) {
            es.execute(new Demo(j));
        }
        Thread.sleep(3000);
        System.out.println(list.size());
        es.shutdown();
    }
}

在每个线程内部有一块存储区域叫做ThreadLocalMap
可以看到,ThreadLocal采用set,get存取值方式
只有线程完全关闭时,在ThreadLocalMap中的数据才会被GC回收
这时有一个值得考虑的问题
我们使用线程池来开发的时候,线程池中的线程并不会关闭,它只是处于空闲状态
也就是说,我们如果把过大的数据存储在当前线程的ThreadLocalMap中,线程不断的调用,被空闲...
最后会导致内存溢出
解决方法是当不需要这些数据时
使用ThreadLocal.remove()方法将变量给移除
CAS操作
还有一种脱离锁的机制,那就是CAS
CAS带着三个变量,分别是:
V更新变量:需要返回的变量
E预期值:原来的值
N新值,传进来的新变量
只有当预期值和新值相等时,才会把V=N,如果不相等,说明该操作会让数据无法同步
根据上面的解释,大概就能知道CAS其实也是在保护数据的同步性
当多个线程进行CAS操作时,可想只有一个线程能成功更新,之后其它线程的E和V会不地进行断比较
所以CAS的同步锁的实现是一样的
CAS操作的并发包在Atomic包中,atomic实现了很多类型
不管是AtomicInteger还是AtomicReference,都有相同点,请观察它们的源码:

private volatile V value;
private static final long valueOffset;

以上是AtomicReferenc

private volatile int value;
private static final long valueOffset;

以上是AtomicIntege
都有value,这是它们的当前实际值

valueOffset保存的是value的偏移量
下面给出一个简单的AtomicIntege例子:

public class AtomicTest {
    public static AtomicInteger atomicInteger = new AtomicInteger();
    //public static AtomicReference atomicReference = new AtomicReference();
    public static class Demo implements Runnable{
        @Override
        public void run() {
            for (int j=0;j<1000;j++){
                atomicInteger.incrementAndGet();        //当前值加1并且返回当前值
            }
        }
    }
    public static void main(String[] args) throws InterruptedException {
        ExecutorService es = Executors.newFixedThreadPool(10);
        for (int i =0;i<10;i++){
            es.submit(new Demo());
        }
        Thread.sleep(5000);
        System.out.println(atomicInteger);
    }
}

你试着执行一下,如果打印出10000说明线程安全

使用CAS操作比同步锁拥有更好的性能
我们来看下incrementAndGet()的源码:

public final int incrementAndGet() {
        return unsafe.getAndAddInt(this, valueOffset, 1) + 1;
    }

来看下getAndAddInt()源码:

public final int getAndAddInt(Object var1, long var2, int var4) {
        int var5;
        do {
            var5 = this.getIntVolatile(var1, var2);
        } while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));
        return var5;
    }

这里有一个循环,再细看源码发现是native的,虽然看不到原生代码,但是可以看出它这里做了一个CAS操作,不断地进行多个变量的比较,只有预设值和新值相等时,才跳出循环
var5就是需要更新的变量,var1和var2是预设值和新值
死锁
讲了那么多无锁的操作,我们来看一下一个死锁的现象
两个线程互相占着对方想得到的锁,就会出现死锁状况

public class DeadLock extends Thread{
    protected String suo;
    public static String zuo = new String();
    public static String you = new String();
    public DeadLock(String suo){
        this.suo=suo;
    }
    @Override
    public void run(){
        if (suo==zuo){
            synchronized (zuo){
                System.out.println("拿到了左,正在拿右......");
                synchronized (you){
                    System.out.println("拿到了右,成功了");
                }
            }
        }
        if (suo==you){
            synchronized (you){
                System.out.println("拿到了右,正在拿左......");
                synchronized (zuo){
                    System.out.println("拿到了zuo,成功了");
                }
            }
        }
    }
    public static void main(String[] args) throws InterruptedException {
        for (int i=0;i<10000;i++){
            DeadLock t1 = new DeadLock(zuo);
            DeadLock t2 = new DeadLock(you);
            t1.start();t2.start();
        }
        Thread.sleep(50000);
    }
}

如图:

image

出现了两个线程的死锁现象,所以说去锁不仅能提升性能,也能防止死锁的产生。

文章来源:https://segmentfault.com/a/1190000012218687

更多参考内容请登录:http://www.roncoo.com/article/index?tn=%E9%AB%98%E5%B9%B6%E5%8F%91

相关文章
|
26天前
|
缓存 监控 Java
Java 线程池在高并发场景下有哪些优势和潜在问题?
Java 线程池在高并发场景下有哪些优势和潜在问题?
|
1月前
|
设计模式 缓存 Java
Java高并发处理机制
Java高并发处理机制
23 1
|
1月前
|
消息中间件 前端开发 Java
java高并发场景RabbitMQ的使用
java高并发场景RabbitMQ的使用
99 0
|
2月前
|
缓存 监控 安全
如何提高 Java 高并发程序的性能?
以下是提升Java高并发程序性能的方法:优化线程池设置,减少锁竞争,使用读写锁和无锁数据结构。利用缓存减少重复计算和数据库查询,并优化数据库操作,采用连接池和分库分表策略。应用异步处理,选择合适的数据结构如`ConcurrentHashMap`。复用对象和资源,使用工具监控性能并定期审查代码,遵循良好编程规范。
|
3月前
|
Java
"揭秘Java IO三大模式:BIO、NIO、AIO背后的秘密!为何AIO成为高并发时代的宠儿,你的选择对了吗?"
【8月更文挑战第19天】在Java的IO编程中,BIO、NIO与AIO代表了三种不同的IO处理机制。BIO采用同步阻塞模型,每个连接需单独线程处理,适用于连接少且稳定的场景。NIO引入了非阻塞性质,利用Channel、Buffer与Selector实现多路复用,提升了效率与吞吐量。AIO则是真正的异步IO,在JDK 7中引入,通过回调或Future机制在IO操作完成后通知应用,适合高并发场景。选择合适的模型对构建高效网络应用至关重要。
86 2
|
3月前
|
监控 算法 Java
企业应用面临高并发等挑战,优化Java后台系统性能至关重要
随着互联网技术的发展,企业应用面临高并发等挑战,优化Java后台系统性能至关重要。本文提供三大技巧:1)优化JVM,如选用合适版本(如OpenJDK 11)、调整参数(如使用G1垃圾收集器)及监控性能;2)优化代码与算法,减少对象创建、合理使用集合及采用高效算法(如快速排序);3)数据库优化,包括索引、查询及分页策略改进,全面提升系统效能。
49 0
|
4月前
|
算法 Java 调度
高并发架构设计三大利器:缓存、限流和降级问题之使用Java代码实现令牌桶算法问题如何解决
高并发架构设计三大利器:缓存、限流和降级问题之使用Java代码实现令牌桶算法问题如何解决
|
4月前
|
监控 网络协议 Java
Java面试题:解释Java NIO与BIO的区别,以及NIO的优势和应用场景。如何在高并发应用中实现NIO?
Java面试题:解释Java NIO与BIO的区别,以及NIO的优势和应用场景。如何在高并发应用中实现NIO?
75 0
|
4月前
|
设计模式 安全 NoSQL
Java面试题:设计一个线程安全的单例模式,并解释其内存占用和垃圾回收机制;使用生产者消费者模式实现一个并发安全的队列;设计一个支持高并发的分布式锁
Java面试题:设计一个线程安全的单例模式,并解释其内存占用和垃圾回收机制;使用生产者消费者模式实现一个并发安全的队列;设计一个支持高并发的分布式锁
68 0
|
4月前
|
设计模式 安全 Java
Java面试题:如何实现一个线程安全的单例模式,并确保其在高并发环境下的内存管理效率?如何使用CyclicBarrier来实现一个多阶段的数据处理任务,确保所有阶段的数据一致性?
Java面试题:如何实现一个线程安全的单例模式,并确保其在高并发环境下的内存管理效率?如何使用CyclicBarrier来实现一个多阶段的数据处理任务,确保所有阶段的数据一致性?
65 0