所谓单例模式,简单来说,就是在整个应用中保证只有一个类的实例存在。就像是Java Web中的application,也就是提供了一个全局变量,用处相当广泛,比如保存全局数据,实现全局性的操作等。

1. 最简单的实现

首先,能够想到的最简单的实现是,把类的构造函数写成private的,从而保证别的类不能实例化此类,然后在类中提供一个静态的实例并能够返回给使用者。这样,使用者就可以通过这个引用使用到这个类的实例了。

public class ReYoSingletonClass { 

  private static final ReYoSingletonClass instance = new ReYoSingletonClass(); 

  public static ReYoSingletonClass getInstance() {
return instance;
} private ReYoSingletonClass() { } } 如上例,外部使用者如果需要使用ReYoSingletonClass的实例,只能通过getInstance()方法,并且它的构造方法是private的,这样就保证了只能有一个对象存在。 2. 性能优化——lazy loaded 上面的代码虽然简单,但是有一个问题——无论这个类是否被使用,都会创建一个instance对象。如果这个创建过程很耗时,比如需要连接10000次数据库(夸张了…:-)),并且这个类还并不一定会被使用,那么这个创建过程就是无用的。怎么办呢? 为了解决这个问题,我们想到了新的解决方案: public class ReYoSingletonClass { private static ReYoSingletonClass instance = null; public static ReYoSingletonClass getInstance() {
if(instance == null) {
instance = new ReYoSingletonClass();
}
return instance;
} private ReYoSingletonClass() { } } 代码的变化有两处——首先,把instance初始化为null,直到第一次使用的时候通过判断是否为null来创建对象。因为创建过程不在声明处,所以那个final的修饰必须去掉。 我们来想象一下这个过程。要使用ReYoSingletonClass,调用getInstance()方法。第一次的时候发现instance是null,然后就新建一个对象,返回出去;第二次再使用的时候,因为这个instance是static的,所以已经不是null了,因此不会再创建对象,直接将其返回。 这个过程就成为lazy loaded,也就是迟加载——直到使用的时候才进行加载。 3. 同步 上面的代码很清楚,也很简单。然而就像那句名言:“80%的错误都是由20%代码优化引起的”。单线程下,这段代码没有什么问题,可是如果是多线程,麻烦就来了。我们来分析一下: 线程A希望使用ReYoSingletonClass,调用getInstance()方法。因为是第一次调用,A就发现instance是null的,于是它开始创建实例,就在这个时候,CPU发生时间片切换,线程B开始执行,它要使用ReYoSingletonClass,调用getInstance()方法,同样检测到instance是null——注意,这是在A检测完之后切换的,也就是说A并没有来得及创建对象——因此B开始创建。B创建完成后,切换到A继续执行,因为它已经检测完了,所以A不会再检测一遍,它会直接创建对象。这样,线程A和B各自拥有一个ReYoSingletonClass的对象——单例失败! 解决的方法也很简单,那就是加锁: public class ReYoSingletonClass { private static ReYoSingletonClass instance = null; public synchronized static ReYoSingletonClass getInstance() {
if(instance == null) {
instance = new ReYoSingletonClass();
}
return instance;
} private ReYoSingletonClass() { } } 是要getInstance()加上同步锁,一个线程必须等待另外一个线程创建完成后才能使用这个方法,这就保证了单例的唯一性。 4. 又是性能 上面的代码又是很清楚很简单的,然而,简单的东西往往不够理想。这段代码毫无疑问存在性能的问题——synchronized修饰的同步块可是要比一般的代码段慢上几倍的!如果存在很多次getInstance()的调用,那性能问题就不得不考虑了! 让我们来分析一下,究竟是整个方法都必须加锁,还是仅仅其中某一句加锁就足够了?我们为什么要加锁呢?分析一下出现lazy loaded的那种情形的原因。原因就是检测null的操作和创建对象的操作分离了。如果这两个操作能够原子地进行,那么单例就已经保证了。于是,我们开始修改代码: public class ReYoSingletonClass { private static ReYoSingletonClass instance = null; public static ReYoSingletonClass getInstance() {
synchronized (ReYoSingletonClass.class) {
if(instance == null) {
instance = new ReYoSingletonClass();
}
}
return instance;
} private ReYoSingletonClass() { } } 首先去掉getInstance()的同步操作,然后把同步锁加载if语句上。但是这样的修改起不到任何作用:因为每次调用getInstance()的时候必然要同步,性能问题还是存在。如果……如果我们事先判断一下是不是为null再去同步呢? public class ReYoSingletonClass { private static ReYoSingletonClass instance = null; public static ReYoSingletonClass getInstance() {
if (instance == null) {
synchronized (ReYoSingletonClass.class) {
if (instance == null) {
instance = new ReYoSingletonClass();
}
}
}
return instance;
} private ReYoSingletonClass() { } } 还有问题吗?首先判断instance是不是为null,如果为null,加锁初始化;如果不为null,直接返回instance。 这就是double-checked locking设计实现单例模式。到此为止,一切都很完美。我们用一种很聪明的方式实现了单例模式。 5. 从源头检查 下面我们开始说编译原理。所谓编译,就是把源代码“翻译”成目标代码——大多数是指机器代码——的过程。针对Java,它的目标代码不是本地机器代码,而是虚拟机代码。编译原理里面有一个很重要的内容是编译器优化。所谓编译器优化是指,在不改变原来语义的情况下,通过调整语句顺序,来让程序运行的更快。这个过程成为reorder。 要知道,JVM只是一个标准,并不是实现。JVM中并没有规定有关编译器优化的内容,也就是说,JVM实现可以自由的进行编译器优化。 下面来想一下,创建一个变量需要哪些步骤呢?一个是申请一块内存,调用构造方法进行初始化操作,另一个是分配一个指针指向这块内存。这两个操作谁在前谁在后呢?JVM规范并没有规定。那么就存在这么一种情况,JVM是先开辟出一块内存,然后把指针指向这块内存,最后调用构造方法进行初始化。 下面我们来考虑这么一种情况:线程A开始创建ReYoSingletonClass的实例,此时线程B调用了getInstance()方法,首先判断instance是否为null。按照我们上面所说的内存模型,A已经把instance指向了那块内存,只是还没有调用构造方法,因此B检测到instance不为null,于是直接把instance返回了——问题出现了,尽管instance不为null,但它并没有构造完成,就像一套房子已经给了你钥匙,但你并不能住进去,因为里面还没有收拾。此时,如果B在A将instance构造完成之前就是用了这个实例,程序就会出现错误了! 于是,我们想到了下面的代码: public class ReYoSingletonClass { private static ReYoSingletonClass instance = null; public static ReYoSingletonClass getInstance() {
if (instance == null) {
ReYoSingletonClass sc;
synchronized (ReYoSingletonClass.class) {
sc = instance;
if (sc == null) {
synchronized (ReYoSingletonClass.class) {
if(sc == null) {
sc = new ReYoSingletonClass();
}
}
instance = sc;
}
}
}
return instance;
} private ReYoSingletonClass() { } } 我们在第一个同步块里面创建一个临时变量,然后使用这个临时变量进行对象的创建,并且在最后把instance指针临时变量的内存空间。写出这种代码基于以下思想,即synchronized会起到一个代码屏蔽的作用,同步块里面的代码和外部的代码没有联系。因此,在外部的同步块里面对临时变量sc进行操作并不影响instance,所以外部类在instance=sc;之前检测instance的时候,结果instance依然是null。 不过,这种想法完全是错误的!同步块的释放保证在此之前——也就是同步块里面——的操作必须完成,但是并不保证同步块之后的操作不能因编译器优化而调换到同步块结束之前进行。因此,编译器完全可以把instance=sc;这句移到内部同步块里面执行。这样,程序又是错误的了! 6. 解决方案 说了这么多,难道单例没有办法在Java中实现吗?其实不然! 在JDK 5之后,Java使用了新的内存模型。volatile关键字有了明确的语义——在JDK1.5之前,volatile是个关键字,但是并没有明确的规定其用途——被volatile修饰的写变量不能和之前的读写代码调整,读变量不能和之后的读写代码调整!因此,只要我们简单的把instance加上volatile关键字就可以了。 public class ReYoSingletonClass { private volatile static ReYoSingletonClass instance = null; public static ReYoSingletonClass getInstance() {
if (instance == null) {
synchronized (ReYoSingletonClass.class) {
if(instance == null) {
instance = new ReYoSingletonClass();
}
}
}
return instance;
} private ReYoSingletonClass() { } } 然而,这只是JDK1.5之后的Java的解决方案,那之前版本呢?其实,还有另外的一种解决方案,并不会受到Java版本的影响: public class ReYoSingletonClass { private static class ReYoSingletonClassInstance {
private static final ReYoSingletonClass instance = new ReYoSingletonClass();
} public static ReYoSingletonClass getInstance() {
return ReYoSingletonClassInstance.instance;
} private ReYoSingletonClass() { } } 在这一版本的单例模式实现代码中,我们使用了Java的静态内部类。这一技术是被JVM明确说明了的,因此不存在任何二义性。在这段代码中,因为ReYoSingletonClass没有static的属性,因此并不会被初始化。直到调用getInstance()的时候,会首先加载ReYoSingletonClassInstance类,这个类有一个static的ReYoSingletonClass实例,因此需要调用ReYoSingletonClass的构造方法,然后getInstance()将把这个内部类的instance返回给使用者。由于这个instance是static的,因此并不会构造多次。 由于ReYoSingletonClassInstance是私有静态内部类,所以不会被其他类知道,同样,static语义也要求不会有多个实例存在。并且,JSL规范定义,类的构造必须是原子性的,非并发的,因此不需要加同步块。同样,由于这个构造是并发的,所以getInstance()也并不需要加同步。 至此,我们完整的了解了单例模式在Java语言中的时候,提出了两种解决方案。个人偏向于第二种,并且Effiective Java也推荐的这种方式。

然后我们来看一下性能差:

第二次方式 :

第一种方式:

1. 最简单的实现
 
首先,能够想到的最简单的实现是,把类的构造函数写成private的,从而保证别的类不能实例化此类,然后在类中提供一个静态的实例并能够返回给使用者。这样,使用者就可以通过这个引用使用到这个类的实例了。
 
public class ReYoSingletonClass {

private static final ReYoSingletonClass instance = new ReYoSingletonClass();
    
  public static ReYoSingletonClass getInstance() {
    return instance;
  }
    
  private ReYoSingletonClass() {
     
  }
    
}
 
如上例,外部使用者如果需要使用ReYoSingletonClass的实例,只能通过getInstance()方法,并且它的构造方法是private的,这样就保证了只能有一个对象存在。
 
2. 性能优化——lazy loaded
 
上面的代码虽然简单,但是有一个问题——无论这个类是否被使用,都会创建一个instance对象。如果这个创建过程很耗时,比如需要连接10000次数据库(夸张了…:-)),并且这个类还并不一定会被使用,那么这个创建过程就是无用的。怎么办呢?
 
为了解决这个问题,我们想到了新的解决方案:
 
public class ReYoSingletonClass {

private static ReYoSingletonClass instance = null;
    
  public static ReYoSingletonClass getInstance() {
    if(instance == null) {
      instance = new ReYoSingletonClass();
    }
    return instance;
  }
    
  private ReYoSingletonClass() {
     
  }
    
}
 
代码的变化有两处——首先,把instance初始化为null,直到第一次使用的时候通过判断是否为null来创建对象。因为创建过程不在声明处,所以那个final的修饰必须去掉。
 
我们来想象一下这个过程。要使用ReYoSingletonClass,调用getInstance()方法。第一次的时候发现instance是null,然后就新建一个对象,返回出去;第二次再使用的时候,因为这个instance是static的,所以已经不是null了,因此不会再创建对象,直接将其返回。
 
这个过程就成为lazy loaded,也就是迟加载——直到使用的时候才进行加载。
 
3. 同步
 
上面的代码很清楚,也很简单。然而就像那句名言:“80%的错误都是由20%代码优化引起的”。单线程下,这段代码没有什么问题,可是如果是多线程,麻烦就来了。我们来分析一下:
 
线程A希望使用ReYoSingletonClass,调用getInstance()方法。因为是第一次调用,A就发现instance是null的,于是它开始创建实例,就在这个时候,CPU发生时间片切换,线程B开始执行,它要使用ReYoSingletonClass,调用getInstance()方法,同样检测到instance是null——注意,这是在A检测完之后切换的,也就是说A并没有来得及创建对象——因此B开始创建。B创建完成后,切换到A继续执行,因为它已经检测完了,所以A不会再检测一遍,它会直接创建对象。这样,线程A和B各自拥有一个ReYoSingletonClass的对象——单例失败!
 
解决的方法也很简单,那就是加锁:
 
public class ReYoSingletonClass {

private static ReYoSingletonClass instance = null;
    
  public synchronized static ReYoSingletonClass getInstance() {
    if(instance == null) {
      instance = new ReYoSingletonClass();
    }
    return instance;
  }
    
  private ReYoSingletonClass() {
     
  }
    
}
 
是要getInstance()加上同步锁,一个线程必须等待另外一个线程创建完成后才能使用这个方法,这就保证了单例的唯一性。
 
4. 又是性能
 
上面的代码又是很清楚很简单的,然而,简单的东西往往不够理想。这段代码毫无疑问存在性能的问题——synchronized修饰的同步块可是要比一般的代码段慢上几倍的!如果存在很多次getInstance()的调用,那性能问题就不得不考虑了!
 
让我们来分析一下,究竟是整个方法都必须加锁,还是仅仅其中某一句加锁就足够了?我们为什么要加锁呢?分析一下出现lazy loaded的那种情形的原因。原因就是检测null的操作和创建对象的操作分离了。如果这两个操作能够原子地进行,那么单例就已经保证了。于是,我们开始修改代码:
 
public class ReYoSingletonClass {

private static ReYoSingletonClass instance = null;
    
  public static ReYoSingletonClass getInstance() {
    synchronized (ReYoSingletonClass.class) {
      if(instance == null) {
        instance = new ReYoSingletonClass();
      }
    }     
    return instance;
  }
    
  private ReYoSingletonClass() {
     
  }
    
}
 
首先去掉getInstance()的同步操作,然后把同步锁加载if语句上。但是这样的修改起不到任何作用:因为每次调用getInstance()的时候必然要同步,性能问题还是存在。如果……如果我们事先判断一下是不是为null再去同步呢?
 
public class ReYoSingletonClass {

private static ReYoSingletonClass instance = null;

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

private ReYoSingletonClass() {

}

}
 
还有问题吗?首先判断instance是不是为null,如果为null,加锁初始化;如果不为null,直接返回instance。
 
这就是double-checked locking设计实现单例模式。到此为止,一切都很完美。我们用一种很聪明的方式实现了单例模式。
 
5. 从源头检查
 
下面我们开始说编译原理。所谓编译,就是把源代码“翻译”成目标代码——大多数是指机器代码——的过程。针对Java,它的目标代码不是本地机器代码,而是虚拟机代码。编译原理里面有一个很重要的内容是编译器优化。所谓编译器优化是指,在不改变原来语义的情况下,通过调整语句顺序,来让程序运行的更快。这个过程成为reorder。
 
要知道,JVM只是一个标准,并不是实现。JVM中并没有规定有关编译器优化的内容,也就是说,JVM实现可以自由的进行编译器优化。
 
下面来想一下,创建一个变量需要哪些步骤呢?一个是申请一块内存,调用构造方法进行初始化操作,另一个是分配一个指针指向这块内存。这两个操作谁在前谁在后呢?JVM规范并没有规定。那么就存在这么一种情况,JVM是先开辟出一块内存,然后把指针指向这块内存,最后调用构造方法进行初始化。
 
下面我们来考虑这么一种情况:线程A开始创建ReYoSingletonClass的实例,此时线程B调用了getInstance()方法,首先判断instance是否为null。按照我们上面所说的内存模型,A已经把instance指向了那块内存,只是还没有调用构造方法,因此B检测到instance不为null,于是直接把instance返回了——问题出现了,尽管instance不为null,但它并没有构造完成,就像一套房子已经给了你钥匙,但你并不能住进去,因为里面还没有收拾。此时,如果B在A将instance构造完成之前就是用了这个实例,程序就会出现错误了!
 
于是,我们想到了下面的代码:
 
public class ReYoSingletonClass {

private static ReYoSingletonClass instance = null;

public static ReYoSingletonClass getInstance() {
    if (instance == null) {
      ReYoSingletonClass sc;
      synchronized (ReYoSingletonClass.class) {
        sc = instance;
        if (sc == null) {
          synchronized (ReYoSingletonClass.class) {
            if(sc == null) {
              sc = new ReYoSingletonClass();
            }
          }
          instance = sc;
        }
      }
    }
    return instance;
  }

private ReYoSingletonClass() {

}
    
}
 
我们在第一个同步块里面创建一个临时变量,然后使用这个临时变量进行对象的创建,并且在最后把instance指针临时变量的内存空间。写出这种代码基于以下思想,即synchronized会起到一个代码屏蔽的作用,同步块里面的代码和外部的代码没有联系。因此,在外部的同步块里面对临时变量sc进行操作并不影响instance,所以外部类在instance=sc;之前检测instance的时候,结果instance依然是null。
 
不过,这种想法完全是错误的!同步块的释放保证在此之前——也就是同步块里面——的操作必须完成,但是并不保证同步块之后的操作不能因编译器优化而调换到同步块结束之前进行。因此,编译器完全可以把instance=sc;这句移到内部同步块里面执行。这样,程序又是错误的了!
 
6. 解决方案
 
说了这么多,难道单例没有办法在Java中实现吗?其实不然!
 
在JDK 5之后,Java使用了新的内存模型。volatile关键字有了明确的语义——在JDK1.5之前,volatile是个关键字,但是并没有明确的规定其用途——被volatile修饰的写变量不能和之前的读写代码调整,读变量不能和之后的读写代码调整!因此,只要我们简单的把instance加上volatile关键字就可以了。
 
public class ReYoSingletonClass {

private volatile static ReYoSingletonClass instance = null;

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

private ReYoSingletonClass() {

}
    
}
 
然而,这只是JDK1.5之后的Java的解决方案,那之前版本呢?其实,还有另外的一种解决方案,并不会受到Java版本的影响:
 
public class ReYoSingletonClass {
    
  private static class ReYoSingletonClassInstance {
    private static final ReYoSingletonClass instance = new ReYoSingletonClass();
  }

public static ReYoSingletonClass getInstance() {
    return ReYoSingletonClassInstance.instance;
  }

private ReYoSingletonClass() {

}
    
}
 
在这一版本的单例模式实现代码中,我们使用了Java的静态内部类。这一技术是被JVM明确说明了的,因此不存在任何二义性。在这段代码中,因为ReYoSingletonClass没有static的属性,因此并不会被初始化。直到调用getInstance()的时候,会首先加载ReYoSingletonClassInstance类,这个类有一个static的ReYoSingletonClass实例,因此需要调用ReYoSingletonClass的构造方法,然后getInstance()将把这个内部类的instance返回给使用者。由于这个instance是static的,因此并不会构造多次。
 
由于ReYoSingletonClassInstance是私有静态内部类,所以不会被其他类知道,同样,static语义也要求不会有多个实例存在。并且,JSL规范定义,类的构造必须是原子性的,非并发的,因此不需要加同步块。同样,由于这个构造是并发的,所以getInstance()也并不需要加同步。
 
至此,我们完整的了解了单例模式在Java语言中的时候,提出了两种解决方案。个人偏向于第二种,并且Effiective Java也推荐的这种方式。

探讨一下Java单例设计模式的更多相关文章

  1. Java单例设计模式的实现

    1. 单例设计模式的定义 单例设计模式确保类只有一个实例对象,类本身负责创建自己的对象并向整个系统提供这个实例.在访问这个对象的时候,访问者可以直接获取到这个唯一对象而不必由访问者进行实例化. 单例设 ...

  2. Java——单例设计模式

    设计模式:解决某一类问题最行之有效的方法.Java中23种设计模式:单例设计模式:解决一个类在内存中只存在一个对象. 想要保证对象唯一.1,为了避免其他程序过多建立该类对象.先禁止其他程序建立该类对象 ...

  3. 转:java单例设计模式

    本文转自:http://www.cnblogs.com/yinxiaoqiexuxing/p/5605338.html 单例设计模式 Singleton是一种创建型模式,指某个类采用Singleton ...

  4. Java单例设计模式和多例设计模式

    单例设计模型 教学视频链接:https://edu.aliyun.com/course/1011 1,private不可以在类外部访问,但可以在内部访问 2,此时Singleton类内部的instan ...

  5. java 单例设计模式

    1.饿汉单例设计模式:  步骤 :   1.定义一个私有的静态成员变量来引用对象(私有的静态对象),设置对象唯一.   2.私有化构造方法,防止new对象.   3.创建一个公开的静态方法,返回上面的 ...

  6. java单例设计模式总结及举例

    * 设计模式:前人总结出来的经验,被后人直接拿来使用. * 单例设计模式:一个类只允许有一个对象,将这个对象作为一个全局的访问点,提供出去供大家使用. * 分析: * 1.用户只能有一个对象 * 2. ...

  7. 对Java单例设计模式中懒汉式类定义的讨论

    全世界人民都知道单例设计模式中类的定义分为懒汉式和饿汉式两种,然而今天并不是要把它们做横向比较.实际上,不论饿汉式类的代码看起来有多么美轮美奂,在实际开发中它的效率总是不如懒汉式的.然而在笔试和面试中 ...

  8. Java单例设计模式(实现Java的一个类只有一个对象)

    单例设计模式的定义:单例设计模式是一种软件设计模式,在它的核心包含一个称为单例类的核心类. 核心便是希望一个类只有一个对象.  如何实现类在内存中只有一个对象呢? 第一步:构造私有:第二步:本身提供一 ...

  9. java—单例设计模式

    单例设计模式:保证一个类仅有一个实例,并提供一个访问它的全局访问点. 1.构造方法私有化 2.声明一个本类对象 3.给外部提供一个静态方法获取对象实例 什么时候使用? 1.通过在工具类的设计中使用: ...

随机推荐

  1. Canvas 3D球形文字云动画特效

    Canvas 3D球形文字云动画特效 效果图: 代码如下,复制即可使用: (适用浏览器:360.FireFox.Chrome.Opera.傲游.搜狗.世界之窗. 不支持Safari.IE8及以下浏览器 ...

  2. elasticsearch6.3.2之x-pack6.3.2破解安装并配合kibana使用

    原文链接:https://www.plaza4me.com/article/20180825223826278 由于在elasticsearch在6.3版本之后x-pack是默认安装好的,所以不再需要 ...

  3. Smashing The Browser:From Vulnerability Discovery To Exploit学习记录

    浏览器Fuzz技术 漏洞挖掘 白盒挖掘 代码审计 自动化代码分析 黑盒挖掘 Fuzzing 两种Fuzzing技术 静态Fuzzing 基于变异的 文件.文档 多媒体 bf3 基于生成的 浏览器 重点 ...

  4. CSS3&HTML5各浏览器支持情况一览表

    http://fmbip.com/ CSS3性质(CSS3 Properties) 平台 MAC WIN 浏览器 CHROME FIREFOX OPERA SAFARI CHROME FIREFOX ...

  5. Codeforces Round #533 (Div. 2) E - Helping Hiasat 最大团

    E - Helping Hiasat 裸的最大团,写了一种 2 ^ (m / 2)  * (m / 2)的复杂度的壮压, 应该还有更好的方法. #include<bits/stdc++.h> ...

  6. EntityManager的使用

    1.最基础的查询 CriteriaBuilder cb = entityManager.getCriteriaBuilder(); CriteriaQuery<User> cq = cb. ...

  7. 异常日志框架Exceptionless结合.NET Core(本地部署)

    一.前言 1.分布式异常日志收集框架Exceptionless是开源的工具,根据官方给出的说明: Exceptionless可以为您的ASP.NET.Web API.WebFrm.WPF.控制台和MV ...

  8. seq2seq模型以及其tensorflow的简化代码实现

    本文内容: 什么是seq2seq模型 Encoder-Decoder结构 常用的四种结构 带attention的seq2seq 模型的输出 seq2seq简单序列生成实现代码 一.什么是seq2seq ...

  9. js原型鏈與js繼承解析

    最近在網上看了諸多js原型鏈的解析,說得雲裡霧裡,不明所以.徹底了解後,決定出個博客記錄一下,一是方便後來人學習,二是方便日後複習. 首先,我們來看一下構造函數.原型.實例之間的關係圖: 所以,我們通 ...

  10. hdu 4460 第37届ACM/ICPC杭州赛区H题 STL+bfs

    题意:一些小伙伴之间有朋友关系,比如a和b是朋友,b和c是朋友,a和c不是朋友,则a和c之间存在朋友链,且大小为2,给出一些关系,求出这些关系中最大的链是多少? 求最短路的最大距离 #include& ...