我的疑问和观点：

网上的各位大侠的普遍观点是“懒汉模式是为了在需要实例的时候再创建，可以节省内存的不必要占用。”

情况1：在该类中存在常用的静态方法或者其他静态成员，使用这些静态方法和成员的时候无需实例化对象，这个时候过早的创建实例是占用了内存，这个时候恶汉模式就显现出了弊端。"暂时无用的数据"占据了内存。就像这个恶汉吃了目前不需要的食品占据了恶汉有限的胃空间，而导致恶汉的胃空间分配更加紧张。这个确实是不够完美。

情况2：如果该类没有静态方法和静态成员，那恶汉模式就没任何瑕疵了。而且恶汉模式在多线程环境下也可正常工作。

单例模式是一种常见的设计模式,它要保证全局只有一个实例,那为了保证这个最基本的条件,它必须提供静态的创建方法,作为一个引用.

那这里会出现很有趣的两种行为模式:饿汉式单例模式和懒汉式单例模式.

这两种方式有什么区别呢?

我们从辛辣面的BLOG里取它的例子来说明一下.

public class Singleton {
        private Singleton(){}
        private static Singleton instance = new Singleton();
        public static Singleton getInstance() {
    　　　　return instance;
        }
    }

这个就是一个很常用的饿汉式单例模式,非常容易理解,也就是说只要客户端调用方法:Singleton.getInstance() 就可以使用这个实例,而且是唯一实例.这种使用方式丝毫没有什么限制,任何客户端只要使用该语句就必然可以创建实例.从JAVA语言来说这种方式是最能表现单例模式的了.

同样我们说明懒汉式单例模式仍然使用辛辣面的一个例子:

public class Singleton {
        private Singleton(){}
        private static Singleton instance = null;
        public static synchronized Singleton getInstance() {
    　　　　if (instance == null) {
    　　　　    instance = new Singleton();
    　　　　}
    　　　　return instance;
        }
    }

这也是一个单例模式,但是他和饿汉式有区别,它在创建时使用了线程标示synchronized ,而且在创建时进行了if (instance == null) {
    　　　　    instance = new Singleton();
}

的判断.

这有什么用呢?

呵呵,稍微基础好一些的朋友应该一眼就看出来了,它在客户端调用时会有限制,也就是说不能在静态的客户端方法中对该单例类进行实例化.(当然synchronized 是为了if (instance == null) 而使用的)

其实说到底他们之间的区别也并不是很大,只是一个限制的问题,所以在使用该设计模式时从JAVA模式的角度,我是倾向于使用饿汉式.

在这里也稍微谈谈所谓的double-checked(双重检测),首先申明一下懒汉式并没有使用双重检测的技术,而双重检测是C++语言中的常用技巧之一,如果说它对懒汉式的改造,那就是将方法的标示synchronized 去除,然后在方法体中判断if (instance == null)后使用synchronized{},而在synchronized{}中再次对if (instance == null)进行判断,达到双重检测的目的.但是很可惜这个双重检测对JAVA的编译器不成立,因为instance的检测和对他的申明在时间上并没有严格的先后次序,所以编译器可能会先检测再申明而导致崩溃.

在多线程下单例模式

Abstract

在开发中，如果某个实例的创建需要消耗很多系统资源，那么我们通常会使用惰性加载机制，也就是说只有当使用到这个实例的时候才会创建这个实例，这个好处在单例模式中得到了广泛应用。这个机制在single-threaded环境下的实现非常简单，然而在multi-threaded环境下却存在隐患。本文重点介绍惰性加载机制以及其在多线程环境下的使用方法。（作者numberzero，参考IBM文章《Double-checked locking and the Singleton pattern》，欢迎转载与讨论）

1       单例模式的惰性加载
通常当我们设计一个单例类的时候，会在类的内部构造这个类（通过构造函数，或者在定义处直接创建），并对外提供一个static getInstance方法提供获取该单例对象的途径。例如：

Java代码  
  1. public class Singleton
  2. {
  3. private static Singleton instance = new Singleton();
  4. private Singleton(){
  5. …
  6. }
  7. public static Singleton getInstance(){
  8. return instance;
  9. }
  10. }

这样的代码缺点是：第一次加载类的时候会连带着创建Singleton实例，这样的结果与我们所期望的不同，因为创建实例的时候可能并不是我们需要这个实例的时候。同时如果这个Singleton实例的创建非常消耗系统资源，而应用始终都没有使用Singleton实例，那么创建Singleton消耗的系统资源就被白白浪费了。

为了避免这种情况，我们通常使用惰性加载的机制，也就是在使用的时候才去创建。以上代码的惰性加载代码如下：

Java代码  
  1. public class Singleton{
  2. private static Singleton instance = null;
  3. private Singleton(){
  4. …
  5. }
  6. public static Singleton getInstance(){
  7. if (instance == null)
  8. instance = new Singleton();
  9. return instance;
  10. }
  11. }

这样，当我们第一次调用Singleton.getInstance()的时候，这个单例才被创建，而以后再次调用的时候仅仅返回这个单例就可以了。

2       惰性加载在多线程中的问题
先将惰性加载的代码提取出来：

Java代码  
  1. public static Singleton getInstance(){
  2. if (instance == null)
  3. instance = new Singleton();
  4. return instance;
  5. }

这是如果两个线程A和B同时执行了该方法，然后以如下方式执行：

1.         A进入if判断，此时foo为null，因此进入if内

2.         B进入if判断，此时A还没有创建foo，因此foo也为null，因此B也进入if内

3.         A创建了一个Foo并返回

4.         B也创建了一个Foo并返回

此时问题出现了，我们的单例被创建了两次，而这并不是我们所期望的。

3       各种解决方案及其存在的问题
3.1     使用Class锁机制
以上问题最直观的解决办法就是给getInstance方法加上一个synchronize前缀，这样每次只允许一个现成调用getInstance方法：

Java代码  
  1. public static synchronized Singleton getInstance(){
  2. if (instance == null)
  3. instance = new Singleton();
  4. return instance;
  5. }

这种解决办法的确可以防止错误的出现，但是它却很影响性能：每次调用getInstance方法的时候都必须获得Singleton的锁，而实际上，当单例实例被创建以后，其后的请求没有必要再使用互斥机制了

3.2     double-checked locking
曾经有人为了解决以上问题，提出了double-checked locking的解决方案

Java代码  
  1. public static Singleton getInstance(){
  2. if (instance == null)
  3. synchronized(instance){
  4. if(instance == null)
  5. instance = new Singleton();
  6. }
  7. return instance;
  8. }

让我们来看一下这个代码是如何工作的：首先当一个线程发出请求后，会先检查instance是否为null，如果不是则直接返回其内容，这样避免了进入synchronized块所需要花费的资源。其次，即使第2节提到的情况发生了，两个线程同时进入了第一个if判断，那么他们也必须按照顺序执行synchronized块中的代码，第一个进入代码块的线程会创建一个新的Singleton实例，而后续的线程则因为无法通过if判断，而不会创建多余的实例。

上述描述似乎已经解决了我们面临的所有问题，但实际上，从JVM的角度讲，这些代码仍然可能发生错误。

对于JVM而言，它执行的是一个个Java指令。在Java指令中创建对象和赋值操作是分开进行的，也就是说instance = new Singleton();语句是分两步执行的。但是JVM并不保证这两个操作的先后顺序，也就是说有可能JVM会为新的Singleton实例分配空间，然后直接赋值给instance成员，然后再去初始化这个Singleton实例。这样就使出错成为了可能，我们仍然以A、B两个线程为例：

1.         A、B线程同时进入了第一个if判断

2.         A首先进入synchronized块，由于instance为null，所以它执行instance = new Singleton();

3.         由于JVM内部的优化机制，JVM先画出了一些分配给Singleton实例的空白内存，并赋值给instance成员（注意此时JVM没有开始初始化这个实例），然后A离开了synchronized块。

4.         B进入synchronized块，由于instance此时不是null，因此它马上离开了synchronized块并将结果返回给调用该方法的程序。

5.         此时B线程打算使用Singleton实例，却发现它没有被初始化，于是错误发生了。

4       通过内部类实现多线程环境中的单例模式
为了实现慢加载，并且不希望每次调用getInstance时都必须互斥执行，最好并且最方便的解决办法如下：

Java代码  
  1. public class Singleton{
  2. private Singleton(){
  3. …
  4. }
  5. private static class SingletonContainer{
  6. private static Singleton instance = new Singleton();
  7. }
  8. public static Singleton getInstance(){
  9. return SingletonContainer.instance;
  10. }
  11. }

JVM内部的机制能够保证当一个类被加载的时候，这个类的加载过程是线程互斥的。这样当我们第一次调用getInstance的时候，JVM能够帮我们保证instance只被创建一次，并且会保证把赋值给instance的内存初始化完毕，这样我们就不用担心3.2中的问题。此外该方法也只会在第一次调用的时候使用互斥机制，这样就解决了3.1中的低效问题。最后instance是在第一次加载SingletonContainer类时被创建的，而SingletonContainer类则在调用getInstance方法的时候才会被加载，因此也实现了惰性加载。

双重检测：

6.单例模式（Singleton Pattern）

前面说提到的五种创建模式，主要解决的问题是如何创建对象，获得产品。而单例模式最要关心的则是对象创建的次数以及何时被创建。

Singleton模式可以是很简单的，它的全部只需要一个类就可以完成（看看这章可怜的UML图）。但是如果在“对象创建的次数以及何时被创建”这两点上较真起来，Singleton模式可以相当的复杂，比头五种模式加起来还复杂，譬如涉及到DCL双锁检测（double checked locking）的讨论、涉及到多个类加载器（ClassLoader）协同时、涉及到跨JVM（集群、远程EJB等）时、涉及到单例对象被销毁后重建等。对于复杂的情况，本章中会涉及到其中一些[1]

目的：

希望对象只创建一个实例，并且提供一个全局的访问点。

场景：

Kerrigan对于Zerg来说是个至关重要的灵魂人物，无数的Drone、Zergling、Hydralisk……可以被创造、被牺牲，但是Kerrigan得存在关系到Zerg在这局游戏中的生存，而且Kerrigan是不允许被多次创造的，必须有且只有一个虫族刀锋女王的实例存在，这不是游戏规则，但这是个政治问题。

 

分析：

如前面一样，我们还是尝试使用代码来描述访问Kerrigan的过程，看看下面的UML图，简单得我都不怎么好意思放上来占版面。

图6.1 单例模式的UML图

结构是简单的，只是我们还有一些小小的要求如下：

1.最基本要求：每次从getInstance()都能返回一个且唯一的一个Kerrigan对象。

2.稍微高一点的要求：Kerrigan很忙，很多人找，所以希望这个方法能适应多线程并发访问。

3.再提高一点的要求：Zerg是讲究公务员效率的社会，希望找Kerrigan的方法性能尽可能高。

4.最后一点要求是Kerrigan自己提出的：体谅到Kerrigan太累，希望多些睡觉时间，因此Kerrigan希望实现懒加载（Lazy Load），在需要的时候才被构造。

5.原本打算说还提要处理多ClassLoader、多JVM等情况，不过还是不要把情况考虑的太复杂了，暂且先放过作者吧（-_-#）。

我们第一次写的单例模式是下面这个样子的：

Java代码  
  1. /**
  2. * 实现单例访问Kerrigan的第一次尝试
  3. */
  4. public class SingletonKerriganA {
  5. /**
  6. * 单例对象实例
  7. */
  8. private static SingletonKerriganA instance = null;
  9. public static SingletonKerriganA getInstance() {
  10. if (instance == null) {                              //line A
  11. instance = new SingletonKerriganA();          //line B
  12. }
  13. return instance;
  14. }
  15. }

这个写法我们把四点需求从上往下检测，发现第二点的时候就出了问题，假设这样的场景：两个线程并发调用SingletonKerriganA.getInstance()，假设线程一先判断完instance是否为null，既代码中的line A进入到line B的位置。刚刚判断完毕后，JVM将CPU资源切换给线程二，由于线程一还没执行line B，所以instance仍然是空的，因此线程二执行了new SignletonKerriganA()操作。片刻之后，线程一被重新唤醒，它执行的仍然是new SignletonKerriganA()操作，好了，问题来了，两个Kerrigan谁是李逵谁是李鬼？

紧接着，我们做单例模式的第二次尝试：

Java代码  
  1. /**
  2. * 实现单例访问Kerrigan的第二次尝试
  3. */
  4. public class SingletonKerriganB {
  5. /**
  6. * 单例对象实例
  7. */
  8. private static SingletonKerriganB instance = null;
  9. public synchronized static SingletonKerriganB getInstance() {
  10. if (instance == null) {
  11. instance = new SingletonKerriganB();
  12. }
  13. return instance;
  14. }
  15. }

比起第一段代码仅仅在方法中多了一个synchronized修饰符，现在可以保证不会出线程问题了。但是这里有个很大（至少耗时比例上很大）的性能问题。除了第一次调用时是执行了SingletonKerriganB的构造函数之外，以后的每一次调用都是直接返回instance对象。返回对象这个操作耗时是很小的，绝大部分的耗时都用在synchronized修饰符的同步准备上，因此从性能上说很不划算。

那继续把代码改成下面的样子：

Java代码  
  1. /**
  2. * 实现单例访问Kerrigan的第三次尝试
  3. */
  4. public class SingletonKerriganC {
  5. /**
  6. * 单例对象实例
  7. */
  8. private static SingletonKerriganC instance = null;
  9. public static SingletonKerriganC getInstance() {
  10. synchronized (SingletonKerriganC.class) {
  11. if (instance == null) {
  12. instance = new SingletonKerriganC();
  13. }
  14. }
  15. return instance;
  16. }
  17. }

基本上，把synchronized移动到代码内部是没有什么意义的，每次调用getInstance()还是要进行同步。同步本身没有问题，但是我们只希望在第一次创建Kerrigan实例的时候进行同步，因此我们有了下面的写法——双重锁定检查（DCL）。

Java代码  
  1. /**
  2. * 实现单例访问Kerrigan的第四次尝试
  3. */
  4. public class SingletonKerriganD {
  5. /**
  6. * 单例对象实例
  7. */
  8. private static SingletonKerriganD instance = null;
  9. public static SingletonKerriganD getInstance() {
  10. if (instance == null) {
  11. synchronized (SingletonKerriganD.class) {
  12. if (instance == null) {
  13. instance = new SingletonKerriganD();
  14. }
  15. }
  16. }
  17. return instance;
  18. }
  19. }

看起来这样已经达到了我们的要求，除了第一次创建对象之外，其他的访问在第一个if中就返回了，因此不会走到同步块中。已经完美了吗？

我们来看看这个场景：假设线程一执行到instance = new SingletonKerriganD()这句，这里看起来是一句话，但实际上它并不是一个原子操作（原子操作的意思就是这条语句要么就被执行完，要么就没有被执行过，不能出现执行了一半这种情形）。事实上高级语言里面非原子操作有很多，我们只要看看这句话被编译后在JVM执行的对应汇编代码就发现，这句话被编译成8条汇编指令，大致做了3件事情：

1.给Kerrigan的实例分配内存。

2.初始化Kerrigan的构造器

3.将instance对象指向分配的内存空间（注意到这步instance就非null了）。

但是，由于Java编译器允许处理器乱序执行（out-of-order），以及JDK1.5之前JMM（Java Memory Medel）中Cache、寄存器到主内存回写顺序的规定，上面的第二点和第三点的顺序是无法保证的，也就是说，执行顺序可能是1-2-3也可能是1-3-2，如果是后者，并且在3执行完毕、2未执行之前，被切换到线程二上，这时候instance因为已经在线程一内执行过了第三点，instance已经是非空了，所以线程二直接拿走instance，然后使用，然后顺理成章地报错，而且这种难以跟踪难以重现的错误估计调试上一星期都未必能找得出来，真是一茶几的杯具啊。

DCL的写法来实现单例是很多技术书、教科书（包括基于JDK1.4以前版本的书籍）上推荐的写法，实际上是不完全正确的。的确在一些语言（譬如C语言）上DCL是可行的，取决于是否能保证2、3步的顺序。在JDK1.5之后，官方已经注意到这种问题，因此调整了JMM、具体化了volatile关键字，因此如果JDK是1.5或之后的版本，只需要将instance的定义改成“private volatile static SingletonKerriganD instance = null;”就可以保证每次都去instance都从主内存读取，就可以使用DCL的写法来完成单例模式。当然volatile或多或少也会影响到性能，最重要的是我们还要考虑JDK1.42以及之前的版本，所以本文中单例模式写法的改进还在继续。

代码倒越来越复杂了，现在先来个返璞归真，根据JLS（Java Language Specification）中的规定，一个类在一个ClassLoader中只会被初始化一次，这点是JVM本身保证的，那就把初始化实例的事情扔给JVM好了，代码被改成这样：

Java代码  
  1. /**
  2. * 实现单例访问Kerrigan的第五次尝试
  3. */
  4. public class SingletonKerriganE {
  5. /**
  6. * 单例对象实例
  7. */
  8. private static SingletonKerriganE instance = new SingletonKerriganE();
  9. public static SingletonKerriganE getInstance() {
  10. return instance;
  11. }
  12. }

好吧，如果这种写法是完美的话，那前面那么几大段话就是作者在消遣各位读者。这种写法不会出现并发问题，但是它是饿汉式的，在ClassLoader加载类后Kerrigan的实例就会第一时间被创建，饿汉式的创建方式在一些场景中将无法使用：譬如Kerrigan实例的创建是依赖参数或者配置文件的，在getInstance()之前必须调用某个方法设置参数给它，那样这种单例写法就无法使用了。

再来看看下面这种我觉得能应对较多场景的单例写法：

Java代码  
  1. /**
  2. * 实现单例访问Kerrigan的第六次尝试
  3. */
  4. public class SingletonKerriganF {
  5. private static class SingletonHolder {
  6. /**
  7. * 单例对象实例
  8. */
  9. static final SingletonKerriganF INSTANCE = new SingletonKerriganF();
  10. }
  11. public static SingletonKerriganF getInstance() {
  12. return SingletonHolder.INSTANCE;
  13. }
  14. }

这种写法仍然使用JVM本身机制保证了线程安全问题；由于SingletonHolder是私有的，除了getInstance()之外没有办法访问它，因此它是懒汉式的；同时读取实例的时候不会进行同步，没有性能缺陷；也不依赖JDK版本。

其他单例模式的写法还有很多，如使用本地线程（ThreadLocal）来处理并发以及保证一个线程内一个单例的实现、GoF原始例子中使用注册方式应对单例类需要需要继承时的实现、使用指定类加载器去应对多ClassLoader环境下的实现等等。我们做开发设计工作的时，应当既要考虑到需求可能出现的扩展与变化，也应当避免“幻影需求”导致无谓的提升设计、实现复杂度，最终反而带来工期、性能和稳定性的损失。设计不足与设计过度都是危害，所以说没有最好的单例模式，只有最合适的单例模式。

到这里为止，单例模式本身就先告一段落了，最后在介绍从其他途径屏蔽构造单例对象的方法：

1.直接new单例对象

2.通过反射构造单例对象

3.通过序列化构造单例对象。

对于第一种情况，一般我们会加入一个private或者protected的构造函数，这样系统就不会自动添加那个public的构造函数了，因此只能调用里面的static方法，无法通过new创建对象。

对于第二种情况，反射时可以使用setAccessible方法来突破private的限制，我们需要做到第一点工作的同时，还需要在在ReflectPermission("suppressAccessChecks") 权限下使用安全管理器（SecurityManager）的checkPermission方法来限制这种突破。一般来说，不会真的去做这些事情，都是通过应用服务器进行后台配置实现。

对于第三种情况，如果单例对象有必要实现Serializable接口（很少出现），则应当同时实现readResolve()方法来保证反序列化的时候得到原来的对象。

基于上述情况，将单例模式增加两个方法：

Java代码  
  1. /**
  2. * 能应对大多数情况的单例实现
  3. */
  4. public class SingletonKerrigan implements Serializable {
  5. private static class SingletonHolder {
  6. /**
  7. * 单例对象实例
  8. */
  9. static final SingletonKerrigan INSTANCE = new SingletonKerrigan();
  10. }
  11. public static SingletonKerrigan getInstance() {
  12. return SingletonHolder.INSTANCE;
  13. }
  14. /**
  15. * private的构造函数用于避免外界直接使用new来实例化对象
  16. */
  17. private SingletonKerrigan() {
  18. }
  19. /**
  20. * readResolve方法应对单例对象被序列化时候
  21. */
  22. private Object readResolve() {
  23. return getInstance();
  24. }
  25. }

总结：

本章通过一次次的的尝试，去了解单例模式各种实现方案的优缺点。对双锁锁定检测进行了简单的讨论，相信大家能从各种尝试的演化过程中，明白为何单例模式是最简单而又最复杂的一种构造模式。

各种构造模式之间可以互相比较，但是没有优劣好坏之分，只有确定了上下文环境，才能谈应用什么模式。学习设计模式我觉得也没有必要去强背一些代码模版，应当去理解每种模式的出现的原因和解决的问题，当你发现你的设计需要更大灵活性时，设计便会向着合适的模式演化，这时候你就真正的掌握了设计模式。

单例模式之饿汉VS懒汉相关推荐

  1. 单例模式之饿汉和懒汉（java）

    文章目录 1.前言 2.怎么区分饿汉和懒汉模式 3. 饿汉 4.懒汉 (双重检查 Double Check Lock) 5.饿汉模式在JDK中的应用(Runtime) 6.相关文章 1.前言 面试时, ...

  2. 单例模式之饿汉模式懒汉模式

    前言 单例模式能保证某个类在程序中只存在唯一一份实例,而不会创建出多个实例,比如 JDBC 中的 DataSource 实例就只需要一个.单例模式具体的实现方式有"饿汉" 和 &q ...

  3. 单例模式，饿汉与懒汉

    文章目录 什么是单例模式 单例模式的两种形式 饿汉模式 懒汉模式 懒汉模式与饿汉模式是否线程安全 懒汉模式的优化 什么是单例模式 单例模式其实就是一种设计模式,跟象棋的棋谱一样,给出一些固定的套路帮助 ...

  4. Java单例模式：饿汉与懒汉区别

    单例模式(Singleton Pattern)是 Java 中最简单的设计模式之一.这种类型的设计模式属于创建型模式,它提供了一种创建对象的最佳方式.这种模式涉及到一个单一的类,该类负责创建自己的对象 ...

  5. 单例模式之饿汉、懒汉模式

    目录 1.单例模式 1.1 饿汉模式 1.2 懒汉模式 1.单例模式 单例模式能保证类在程序中只存在唯一一份实例.这一点在很多场景中都需要,比如JDBC中的DataSource实例就只需要一个. 单例 ...

  6. php 懒汉式单例,单例模式：饿汉和懒汉

    接下来就说下单例模式了,这个在实际应用还是比较常用的! 首先,单例分为懒汉式和饿汉式: 饿汉式:类加载的时候,创建对象. 因此类加载速度慢, 线程相对安全 懒汉式:类加载的时候,不会创建对象,调用时才 ...

  7. java单例设计模式双重_Java 设计模式 ——单例模式（饿汉，懒汉，双重锁，静态内部类）...

    设计模式: 是在大量的实践中总结和理论化之后优选的代码结构,编程风格,以及解决问题的思考方式.设计模式免去我们自己再思考和摸索.就像是经典的棋谱,不同的棋局,我们用不同的棋谱 俗称"套路&q ...

  8. 单例模式 (饿汉、懒汉)

    单例模式 定义 单例模式的实现 饿汉模式 懒汉模式 线程安全问题分析: 如何解决线程安全问题?? 关键点总结 定义 单例模式,是一种常见的"设计模式" 设计模式: 设计模式是一套经 ...

  9. 单例模式（饿汉实现、懒汉实现）

    目录 (MS) 1. 饿汉实现 2.  懒汉模式 ① 单线程版本 ② 线程安全版 ③ 线程安全改进版⼀ 以上存在线程安全问题. ④ 线程安全改进版⼆ 以上存在线程安全问题,对象创建需要三步: ⑤ 线程 ...

最新文章

  1. nagios不能 发送飞信报警一例
  2. 洛谷 2953 [USACO09OPEN]牛的数字游戏Cow Digit Game
  3. Ubuntu环境搭建系列—JavaEE篇
  4. 环境部署（java安装和配置，Tomcat安装和配置）（tomcat下部署war包）
  5. python open word_使用Python在OpenOffice / Microsoft Word中格式化输出
  6. CVE-2017-8890漏洞分析与利用（Root Android 7.x）
  7. 浅谈iptables防SYN Flood攻击和CC攻击
  8. CSS教程--CSS背景
  9. Python - SIP参考指南 - 介绍
  10. 跳槽后，获年薪300万，是跳槽还是跳坑
  11. Linq之Lambda进阶
  12. [Swift]判断字符串是否为空
  13. python在冒号处显示语法错误_python for常见语法错误
  14. 【U8+】修改查询凭证列表中的系统名
  15. vs code 的常用快捷键列表
  16. edge保存页面html,Edge浏览器怎么保存网页 保存网页方法介绍
  17. 路由器下一跳地址怎么判断_路由器工作原理（一）
  18. Springboot中Feign的使用方法
  19. Hantek6022BE 虚拟示波器 （二）方波 采样率 带宽
  20. 一文带你搞清楚USB、type-C、雷电三接口之间的区别与联系

热门文章

  1. 时序预测 | MATLAB实现基于Adam算法优化BiLSTM双向长短期记忆神经网络时间序列预测
  2. brk16_Linux进程分配内存的两种方式--brk() 和mmap()
  3. springboot-分布式实例开发（二）
  4. 南卡和小米哪个降噪好？南卡和小米降噪耳机对比测评
  5. background ie8兼容性问题
  6. opencv python搞个写轮眼
  7. vue状态判断。vue过滤器状态判断
  8. 一种简单的随机多边形生成方法
  9. 分布式-4分布式集群
  10. 广州小洲村 1850创意园 一游