「java双肩锁」java双重锁单例模式

博主:adminadmin 2023-03-18 21:24:09 547

今天给各位分享java双肩锁的知识,其中也会对java双重锁单例模式进行解释,如果能碰巧解决你现在面临的问题,别忘了关注本站,现在开始吧!

本文目录一览:

Java中有哪些锁,区别是什么

【1】公平所和非公平所。

公平锁:是指按照申请锁的顺序来获取锁,

非公平所:线程获取锁的顺序不一定按照申请锁的顺序来的。

//默认是不公平锁,传入true为公平锁,否则为非公平锁

ReentrantLock reentrantLock = new ReetrantLock();

1

2

【2】共享锁和独享锁

独享锁:一次只能被一个线程所访问

共享锁:线程可以被多个线程所持有。

ReadWriteLock 读锁是共享锁,写锁是独享锁。

【3】乐观锁和悲观锁。

乐观锁:对于一个数据的操作并发,是不会发生修改的。在更新数据的时候,会尝试采用更新,不断重入的方式,更新数据。

悲观锁:对于同一个数据的并发操作,是一定会发生修改的。因此对于同一个数据的并发操作,悲观锁采用加锁的形式。悲观锁认为,不加锁的操作一定会出问题,

【4】分段锁

1.7及之前的concurrenthashmap。并发操作就是分段锁,其思想就是让锁的粒度变小。

【5】偏向锁是指一段同步代码一直被一个线程所访问,那么该线程会自动获取锁。降低获取锁的代价

轻量级锁

重量级锁

【6】自旋锁

自旋锁

单例模式 java 双重锁用synchronized修饰之后还用volatile吗

没有volatile修饰的uniqueInstance

[java] view plain copy

public class Singleton {

private static Singleton uniqueInstance;

private Singleton(){

}

public static Singleton getInstance(){

if(uniqueInstance == null){ //#1

synchronized(Singleton.class){ //#2

if(uniqueInstance == null){ //#3

uniqueInstance = new Singleton(); //#4

System.out.println(Thread.currentThread().getName() + ": uniqueInstance is initalized..."); //#5.1

} else {

System.out.println(Thread.currentThread().getName() + ": uniqueInstance is not null now..."); //#5.2

}

}

}

return uniqueInstance;

}

}

这样可能会导致结果 Singleton被实例化两次 ,这样就不符合单例的特点

原因分析:

1. thread2进入#1, 这时子线程的uniqueInstance都是为空的,thread2让出CPU资源给thread3

2. thread3进入#1, 这时子线程的uniqueInstance都是为空的, thread3让出CPO资源给thread2

3. thread2会依次执行#2,#3,#4, #5.1,最终在thread2里面实例化了uniqueInstance。thread2执行完毕让出CPO资源给thread3

4. thread3接着#1跑下去,跑到#3的时候,由于#1里面拿到的uniqueInstance还是空(并没有及时从thread2里面拿到最新的),所以thread3仍然会执行#4,#5.1

5. 最后在thread2和thread3都实例化了uniqueInstance

例子2:用volatile修饰的uniqueInstance

这里就不贴重复的代码了,因为只是加多一个volatile来修饰成员变量:uniqueInstance,

这样可以创建出一个单例实例。

原因分析:

volatile(java5):可以保证多线程下的可见性;

读volatile:每当子线程某一语句要用到volatile变量时,都会从主线程重新拷贝一份,这样就保证子线程的会跟主线程的一致。

写volatile: 每当子线程某一语句要写volatile变量时,都会在读完后同步到主线程去,这样就保证主线程的变量及时更新。

1. thread2进入#1, 这时子线程的uniqueInstance都是为空的(java内存模型会从主线程拷贝一份uniqueInstance=null到子线程thread2),thread2让出CPU资源给thread3

2. thread3进入#1, 这时子线程的uniqueInstance都是为空的(java内存模型会从主线程拷贝一份uniqueInstance=null到子线程thread2), thread3让出CPO资源给thread2

3. thread2会依次执行#2,#3,#4, #5.1,最终在thread2里面实例化了uniqueInstance(由于是volatile修饰的变量,会马上同步到主线程的变量去)。thread2执行完毕让出CPO资源给thread3

4. thread3接着#1跑下去,跑到#3的时候,会又一次从主线程拷贝一份uniqueInstance!=null回来,所以thread3就直接跑到了#5.2

5. 最后在thread3不再会重复实例化uniqueInstance了

java锁有哪些类

公平锁/非公平锁

可重入锁

独享锁/共享锁

互斥锁/读写锁

乐观锁/悲观锁

分段锁

偏向锁/轻量级锁/重量级锁

自旋锁

如何在Java中使用双重检查锁实现单例

单例类在Java开发者中非常常用,但是它给初级开发者们造成了很多挑战。他们所面对的其中一个关键挑战是,怎样确保单例类的行为是单例?也就是说,无论任何原因,如何防止单例类有多个实例。在整个应用生命周期中,要保证只有一个单例类的实例被创建,双重检查锁(Double checked locking of Singleton)是一种实现方法。顾名思义,在双重检查锁中,代码会检查两次单例类是否有已存在的实例,一次加锁一次不加锁,一次确保不会有多个实例被创建。顺便提一下,在JDK1.5中,Java修复了其内存模型的问题。在JDK1.5之前,这种方法会有问题。本文中,我们将会看到怎样用Java实现双重检查锁的单例类,为什么Java 5之前的版本双重检查锁会有问题,以及怎么解决这个问题。顺便说一下,这也是重要的面试要点,我曾经在金融业和服务业的公司面试被要求手写双重检查锁实现单例模式、相信我,这很棘手,除非你清楚理解了你在做什么。你也可以阅读我的完整列表“单例模式设计问题”来更好的准备面试。

为什么你需要双重检查锁来实现单例类?

一个常见情景,单例类在多线程环境中违反契约。如果你要一个新手写出单例模式,可能会得到下面的代码:

   private static Singleton _instance;

    public static Singleton getInstance() {

        if (_instance == null) {

            _instance = new Singleton();

        }

        return _instance;

    }

然后,当你指出这段代码在超过一个线程并行被调用的时候会创建多个实例的问题时,他很可能会把整个getInstance()方法设为同步(synchronized),就像我们展示的第二段示例代码getInstanceTS()方法一样。尽管这样做到了线程安全,并且解决了多实例问题,但并不高效。在任何调用这个方法的时候,你都需要承受同步带来的性能开销,然而同步只在第一次调用的时候才被需要,也就是单例类实例创建的时候。这将促使我们使用双重检查锁模式(double checked locking pattern),一种只在临界区代码加锁的方法。程序员称其为双重检查锁,因为会有两次检查 _instance == null,一次不加锁,另一次在同步块上加锁。这就是使用Java双重检查锁的示例:

   public static Singleton getInstanceDC() {

        if (_instance == null) {                // Single Checked

            synchronized (Singleton.class) {

                if (_instance == null) {        // Double checked

                    _instance = new Singleton();

                }

            }

        }

        return _instance;

    }

这个方法表面上看起来很完美,你只需要付出一次同步块的开销,但它依然有问题。除非你声明_instance变量时使用了volatile关键字。没有volatile修饰符,可能出现Java中的另一个线程看到个初始化了一半的_instance的情况,但使用了volatile变量后,就能保证先行发生关系(happens-before relationship)。对于volatile变量_instance,所有的写(write)都将先行发生于读(read),在Java 5之前不是这样,所以在这之前使用双重检查锁有问题。现在,有了先行发生的保障(happens-before guarantee),你可以安全地假设其会工作良好。另外,这不是创建线程安全的单例模式的最好方法,你可以使用枚举实现单例模式,这种方法在实例创建时提供了内置的线程安全。另一种方法是使用静态持有者模式(static holder pattern)。

   /*

     * A journey to write double checked locking of Singleton class in Java.

     */

    class Singleton {

        private volatile static Singleton _instance;

        private Singleton() {

            // preventing Singleton object instantiation from outside

        }

        /*

         * 1st version: creates multiple instance if two thread access

         * this method simultaneously

         */

        public static Singleton getInstance() {

            if (_instance == null) {

                _instance = new Singleton();

            }

            return _instance;

        }

       /*

        * 2nd version : this definitely thread-safe and only

        * creates one instance of Singleton on concurrent environment

        * but unnecessarily expensive due to cost of synchronization

        * at every call.

        */

       public static synchronized Singleton getInstanceTS() {

           if (_instance == null) {

               _instance = new Singleton();

           }

           return _instance;

       }

       /*

        * 3rd version : An implementation of double checked locking of Singleton.

        * Intention is to minimize cost of synchronization and  improve performance,

        * by only locking critical section of code, the code which creates instance of Singleton class.

        * By the way this is still broken, if we don't make _instance volatile, as another thread can

        * see a half initialized instance of Singleton.

        */

        public static Singleton getInstanceDC() {

            if (_instance == null) {

                synchronized (Singleton.class) {

                    if (_instance == null) {

                        _instance = new Singleton();

                    }

                }

            }

            return _instance;

        }

    }

这就是本文的所有内容了。这是个用Java创建线程安全单例模式的有争议的方法,使用枚举实现单例类更简单有效。我并不建议你像这样实现单例模式,因为用Java有许多更好的方式。但是,这个问题有历史意义,也教授了并发是如何引入一些微妙错误的。正如之前所说,这是面试中非常重要的一点。在去参加任何Java面试之前,要练习手写双重检查锁实现单例类。这将增强你发现Java程序员们所犯编码错误的洞察力。另外,在现在的测试驱动开发中,单例模式由于难以被模拟其行为而被视为反模式(anti pattern),所以如果你是测试驱动开发的开发者,最好避免使用单例模式。

JAVA的琐是什么?有几种锁?几种锁的区别又是什么?

众所周知,java开发语言提供了很方便的开发平台,而且开发出来的程序很容易在不同的平台上面进行移植,现在越来越多的人使用它开发软件。

Java有了它方便的一个方面,但是他同时也带给了开发者一个烦恼,这就是保护的办法不多,而且大多数不是很好用,这样自己辛苦开发出来的程序很容易被人复制而据为己有,一般情况下,大多数的人都是用混编器(java obfuscator)来把开发出来的程序进行打乱以达到没有办法来反编译观看源代码,但是这种办法在网上很容易找到相关的软件来重新整理,那么这个混编只能控制一些本来也没有办法动您的软件的人,而对于一些掌握工具的人几乎是透明的,还有就是利用硬件加密锁,但大多数公司提供的硬件加密锁只是提供了一些dll的连接或简单的api调用,只要反编译他们,就很容易把一些api调用去掉,这样硬件加密锁也就不起作用了,但是现在到底有没有好的办法呢?

以色列阿拉丁公司提供的*** HL加密锁提供的外壳加密工具中有一个叫做数据加密的功能,这个功能能更好的防止去除api的调用,各位都知道:硬件加密锁的保护原理就是要您被加密过的软件和加密锁的硬件要紧紧地结合在一起,而且不容易被轻易的剔出原来的调用,这样才能更好的保证您的软件不被盗版,同时这种方式也很容易被程序员掌握,要对一个软件实现保护,只需要几分钟的时间就可以了,下面简单介绍一下他的原理:

运用阿拉丁公司提供的外壳工具先把调用您的java解释器来进行加密,那么就是说如果要运用这个解释器就需要有一把特定的加密锁存在,然后我们再运用它提供的外壳加密工具中的内容加密,把您写好的java程序当作一个文件来处理而对他进行加密,这个加密是采用的AES128位的算法的,这样这个加密过的数据文件??您的软件就只能被您保护过的java解释器来进行解释,但是在没有加密锁的情况下就不能够运行您的软件,从而达到真正保护您的软件的目的。

在java中有哪些锁

给你整理了Java中的一些锁:

公平锁/非公平锁

可重入锁

独享锁/共享锁

互斥锁/读写锁

乐观锁/悲观锁

分段锁

偏向锁/轻量级锁/重量级锁

自旋锁

上面是很多锁的名词,这些分类并不是全是指锁的状态,有的指锁的特性,有的指锁的设计

java双肩锁的介绍就聊到这里吧,感谢你花时间阅读本站内容,更多关于java双重锁单例模式、java双肩锁的信息别忘了在本站进行查找喔。