java中关于单例和静态的区别类的区别

来源：蜘蛛抓取(WebSpider) 时间：2018-08-28 16:28 标签： 单例和静态的区别

单例模式和静态对象的销毁 [问题点数：30分，结帖人EnjoySilence]

置null是一个办法。
但是没解决根本性问题，因为类未被卸载。
事实上类的卸载根本不由你控制。

假设你改了一个BUG，类名没有变，


你删除当前插件，然后马上安装新插件，
结果往往是调来的还是老插件，因为原来的类没被卸载。
通常解决的办法是用classloader，但这依赖与母程序的构架设计。

要实现或者学习热插件系统，


可以参看OSGi规范，以及他的开源实现。

个人觉得，Hadson 也是一个比较好的热插件系统范例，


可以看看Hudson源码。
额，在单例类里加个public方法把这个静态实例变量赋值为null是不是就行了

这个方法只适用于类似下面的Singleton实现方式：

对于性能的追求是永无止境的，此文只做抛砖引玉，欢迎讨论。 用好对象池绝对能提高很多项目的执行效率，下面结合我在《消灭方块》的开发介绍一下对象池的应用。
最近学习了一下单例模式，突然想到一些自己写代码的时候产生的工具类（静态方法）于是就想到了两者的区别，在网上也搜集了一些资料，但是都是大同小异没什么大的区别，这里做一下整理和写一下自己的理解1、单例可以继承类，实现接口，而静态类不能（可以集成类，但不能集成实例成员）； 2、单例可以被延迟初始化，静态类一般在第一次加载时初始化； 3、单例类可以被集成，他的方法可以被覆写
观点一：（单例） 单例模式比静态方法有很多优势： 首先，单例可以继承类，实现接口，而静态类不能（可以集成类，但不能集成实例成员）； 其次，单例可以被延迟初始化，静态类一般在第一次加载是初始化； 再次，单例类可以被集成，他的方法可以被覆写； 最后，或许最重要的是，单例类可以被用于多态而无需强迫用户只假定唯一的实例。举个例子，你可能在开始时只写一个配置，但是以后你可能需要支持超过一个配置集，
单例模式也称为单件模式、单子模式，可能是使用最广泛的设计模式。其意图是保证一个类仅有一个实例，并提供一个访问它的全局访问点，该实例被所有程序模块共享。有很多地方需要这样的功能模块，如系统的日志输出，GUI应用必须是单鼠标，MODEM的联接需要一条且只需要一条电话线，操作系统只能有一个窗口管理器，一台PC连一个键盘。   单例模式有许多种实现方法，在C++中，甚至可以直接用一个全局变量做到这一点
hotspot虚拟机的垃圾收集算法使用根搜索算法。这个算法的基本思路是：对任何“活”的对象，一定能最终追溯到其存活在堆栈或静态存储区之中的引用。通过一系列名为根（GC Roots）的引用作为起点，从这些根开始搜索，经过一系列的路径，如果可以到达java堆中的对象，那么这个对象就是“活”的，是不可回收的。可以作为根的对象有： 虚拟机栈（栈桢中的本地变量表）中的引用的对象。 方法区中的类静态属性引用的对
最复杂的写法没想到反而是最好的写法

单例模式与静态类（一个类，所有方法为静态方法）是另一个非常有趣的问题，在《中有关单例模式的面试问题》博文中露掉了，由于单例模式和静态类都具有良好的访问性，它们之间有许多相似之处，例如，两者可以直接使用而无须创建对象，都可提交唯一实例，在一个非常高的高度上看起来它们都为是用于同样的任务。由于它们具有较多的相似性，面试官常常会问一些类似为神马使用单例模式替换静态方法？你能使用静态类替换单例模式吗？Java中单例模式与静态的区别有那些？等这样的问题，为回答这些问题，记住他们单例模式和静态方法之间基本的区别是非常重要的，前者给你一个Object，后者仅仅提供静态方法，由于对像比方法具有较强的能力，可以指导你神马时候使用单例模式与静态方法。

在本文中，我们会了解神马Java中的神马地方使用单例模式，神马时候使用静态类更好，顺便说下，JDK中有几个关于两者的例子，并且这例子非常聪明的，例如java.lang.Math是一个final类，并且其方法为静态方法，另一方面java.lang.Runtime是一个单例的类。对于那些不熟悉单例模式或静态类的人，静态类就是一个Java类，它仅包含静态方法，一个非常好静态类的例子就是java.lang.Math，它包括了许多为不同数据功能实现工具方法，例如sqrt()，而单例类，在整个应用生命周期内只有一个实例，例如java.lang.Runtime。

神马时候在Java中使用静态类替换单例

确实存在一些场景，静态类比单例更适合，这个场景中主要的一个例子就是java.lang.Math，它不是单例的，其所有方法都是静态方法，这里我给出几个场景，我觉得使用静态类比单例模式更适合。

1)        如果你的单例不需要维护任何状态，仅仅提供全局访问的方法，这种情况考虑使用静态类，静态方法比单例更快，因为静态的绑定是在编译期就进行的。但是要记住，不建议在静态类中维护状态信息，特别是在并发环境中，若无适当的同步措施而修改多线程并发时，会导致坏的竞态条件。

如果你需要将一些工具方法集中在一起时，你可以选择使用静态方法，但是别的东西，要求单例访问资源时，应该使用单例模式。

Java中单例与静态的区别

这是回答关于单例与静态的第二面试问题，如我早些提到过的，它们基本的区别一个表现类，一个表现方法，下面列几条它们之间的区别。

2)        再次，它们的区别是override的能力，因Java中的静态方法是不可以覆盖的，这就导致其木有太多的灵活性，另一面，你可通过继承的方式覆盖单例类中定义的方法。

3)        静态类很难模拟，因此难于单例测试，单例更容易模拟，因为也比静态类易于编写单元测试，不论神马单例期望神马，你都可以传递模拟对象，例如构造方法或方法参数。

4)        如果你的需求中需要维护状态信息，则单例比静态类更适合，因为后者在维护状态信息方面是非常可怕的，并导致狡滑的bug。

5)        如果是一个非常重的对象，单例可以懒加载，但是静态类没有这样的优势，并且非常热切的加载。

两者之间的这些区别，有助于我们在面对一些场景时做出选择，下一节中了解神马时候选择单例而不是静态类。

Java中，选择单例而不是静态类的优点

单例与静态主要的优点是前者比后者更具有面向对象的能力，使用单例，可以通过继承和多态扩展基类，实现接口和更有能力提供不同的实现，如果我们讨论java.lang.Runtime，在Java中它是单例，调用getRuntime()方法，会基于不同的JVM返回不同的实现，但也保证了每个JVM中实有一个实例，如果java.lang.Runtime是一个静态类，不太可能因不同的JVM返回不同的实现。

这就是Java中单例与静态类的区别，当你需要一个全OO能力的对象时，选择单例，如果仅仅是将一些静态方法预售，使用静态类。

单例模式可能是代码最少的模式了，但是少不一定意味着简单，想要用好、用对单例模式，还真得费一番脑筋。本文对Java中常见的单例模式写法做了一个总结，如有错漏之处，恳请读者指正。

顾名思义，饿汉法就是在第一次引用该类的时候就创建对象实例，而不管实际是否需要创建。代码如下：

这样做的好处是编写简单，但是无法做到延迟创建对象。但是我们很多时候都希望对象可以尽可能地延迟加载，从而减小负载，所以就需要下面的懒汉法：

这种写法是最简单的，由私有构造器和一个公有静态工厂方法构成，在工厂方法中对singleton进行null判断，如果是null就new一个出来，最后返回singleton对象。这种方法可以实现延时加载，但是有一个致命弱点：线程不安全。如果有两条线程同时调用getSingleton()方法，就有很大可能导致重复创建对象。

这种写法考虑了线程安全，将对singleton的null判断以及new的部分使用synchronized进行加锁。同时，对singleton对象使用volatile关键字进行限制，保证其对所有线程的可见性，并且禁止对其进行指令重排序优化。如此即可从语义上保证这种单例模式写法是线程安全的。注意，这里说的是语义上，实际使用中还是存在小坑的，会在后文写到。

兼顾线程安全和效率的写法

虽然上面这种写法是可以正确运行的，但是其效率低下，还是无法实际应用。因为每次调用getSingleton()方法，都必须在synchronized这里进行排队，而真正遇到需要new的情况是非常少的。所以，就诞生了第三种写法：

这种写法被称为“双重检查锁”，顾名思义，就是在getSingleton()方法中，进行两次null检查。看似多此一举，但实际上却极大提升了并发度，进而提升了性能。为什么可以提高并发度呢？就像上文说的，在单例中new的情况非常少，绝大多数都是可以并行的读操作。因此在加锁前多进行一次null检查就可以减少绝大多数的加锁操作，执行效率提高的目的也就达到了。

那么，这种写法是不是绝对安全呢？前面说了，从语义角度来看，并没有什么问题。但是其实还是有坑。说这个坑之前我们要先来看看volatile这个关键字。其实这个关键字有两层语义。第一层语义相信大家都比较熟悉，就是可见性。可见性指的是在一个线程中对该变量的修改会马上由工作内存（Work Memory）写回主内存（Main Memory），所以会马上反应在其它线程的读取操作中。顺便一提，工作内存和主内存可以近似理解为实际电脑中的高速缓存和主存，工作内存是线程独享的，主存是线程共享的。volatile的第二层语义是禁止指令重排序优化。大家知道我们写的代码（尤其是多线程代码），由于编译器优化，在实际执行的时候可能与我们编写的顺序不同。编译器只保证程序执行结果与源代码相同，却不保证实际指令的顺序与源代码相同。这在单线程看起来没什么问题，然而一旦引入多线程，这种乱序就可能导致严重问题。volatile关键字就可以从语义上解决这个问题。

注意，前面反复提到“从语义上讲是没有问题的”，但是很不幸，禁止指令重排优化这条语义直到jdk1.5以后才能正确工作。此前的JDK中即使将变量声明为volatile也无法完全避免重排序所导致的问题。所以，在jdk1.5版本前，双重检查锁形式的单例模式是无法保证线程安全的。

那么，有没有一种延时加载，并且能保证线程安全的简单写法呢？我们可以把Singleton实例放到一个静态内部类中，这样就避免了静态实例在Singleton类加载的时候就创建对象，并且由于静态内部类只会被加载一次，所以这种写法也是线程安全的：

但是，上面提到的所有实现方式都有两个共同的缺点：

  • 都需要额外的工作(Serializable、transient、readResolve())来实现序列化，否则每次反序列化一个序列化的对象实例时都会创建一个新的实例。

  • 可能会有人使用反射强行调用我们的私有构造器（如果要避免这种情况，可以修改构造器，让它在创建第二个实例的时候抛异常）。

当然，还有一种更加优雅的方法来实现单例模式，那就是枚举写法：

使用枚举除了线程安全和防止反射强行调用构造器之外，还提供了自动序列化机制，防止反序列化的时候创建新的对象。因此，Effective Java推荐尽可能地使用枚举来实现单例。

这篇文章发出去以后得到许多反馈，这让我受宠若惊，觉得应该再写一点小结。代码没有一劳永逸的写法，只有在特定条件下最合适的写法。在不同的平台、不同的开发环境（尤其是jdk版本）下，自然有不同的最优解（或者说较优解）。

再比如双重检查锁法，不能在jdk1.5之前使用，而在Android平台上使用就比较放心了（一般Android都是jdk1.6以上了，不仅修正了volatile的语义问题，还加入了不少锁优化，使得多线程同步的开销降低不少）。

最后，不管采取何种方案，请时刻牢记单例的三大要点：

《深入理解Java虚拟机——JVM高级特性与最佳实践（第二版）》

我要回帖

更多关于 单例和静态的区别 的文章

 

随机推荐