园区网互联及网站建设搜狗seo查询
wait和sleep的区别
我们的wait也是提供了一个还有超时时间的版本，sleep也是可以指定时间的，也就是说时间一到就会解除阻塞，继续执行
wait和sleep都能被提前唤醒(虽然时间还没有到也可以提前唤醒)，wait能被notify提前唤醒，sleep能被interrupt提前唤醒
我们使用wait大多是不知道要等多少时间的前提下使用的，我们的所谓的超时时间其实是用来兜底的，大多数情况下，wait是再超时时间之内就被唤醒了，比如我们设置的超时时间是1000ms，大多数的情况我们100ms或者200ms就提前唤醒了，只有小于1%的情况才会触发超时
使用sleep，一定是知道要等多少时间的情况下使用的，虽然可以被提前唤醒，但是通过异常的方式唤醒，这个操作不应该作为正常的业务流程，比如我们sleep了1000ms，大多数的情况下我们是期望1000ms是准时的，被异常唤醒只少数的极端情况，sleep的唤醒是通过异常的方式，正常的业务逻辑不应该依赖于异常的处理，异常的处理我们认为是在做一些补救的措施
多线程代码案例
单例模式
单里模式是一种设计模式
什么是设计模式呢?
设计模式和框架都是程序员需要掌握的技能，只不过框架是硬性的规定，而设计模式是软性的规定，这些都是大佬设计出来的，即使是一个代码写的不好的程序员根据这些写代码也能写出还可以的代码，遵守设计模式，代码的下限就被兜住了，设计模式就像棋谱一样，按照棋谱来走的话，你下的棋不会很差，但是你不一定非要按照棋谱的方式来下棋，也许你下棋会比棋谱很好
设计模式有很多种，不同的语言当中，也有不同的设计模式(设计模式也可以认为是对编程语言语法的补充)
单例模式：单例就是单个实例(对象)，某个类在进程中，只应该创建出一个实例(原则上不应该有多个)，使用单例模式就可以对咱们的代码进行一个更严格的校验和检查，比如，有时候代码中我们用一个对象来管理/持有大量的数据，我们只需要这一个对象就可以了，假设这个对象管理了10G的数据，如果我们不小多创建出来几个对象的话，内存空间就就会成倍的增长，我们的机器就可能顶不住
如何保证对象的唯一性呢？
我们可以搞一个“君子协议”，写一个文档，文档上面规定只能有一个对象，每个接手的程序员都要遵守这个文档，不能将这个类创建多个实例，但是这种约定是不靠谱的，Java本身的语法并没有规定一个类可以创建多少个对象，于是我们就要通过一些“奇淫巧计”来实现这样的效果
实现单例模式的方式有很多种的，这里我们介绍最基础的实现方式：
1.饿汉模式
2.懒汉模式
饿汉模式
我们现在写一个Singleton类，我们要求这个类只能有拥有唯一的实例
上图的这个实例就是我们希望创建出的唯一的实例
为什么这就是唯一的呢？
我们注意到我们这个实例前面添加了static，就是静态的意思，也可以理解为是类属性，所以我们这一个实例是属于类对象里面的属性，我们知道每个类的类对象只有一个，所以我们的类属性自然也是只有一个了，此时instanc指向的这个对象就是唯一的一个对象了
其他的代码要是想要获取这个类的实例的话，就要通过这个方法来进行获取，不应该通过new再获取新的对象，而是通过这个方法获取到现成的对象
我们直接将构造方法设置为私有的就保证了其他代码不能在new一个对象，只能调用getInstance方法来获取实例(如下图)
SIngleton内部已经将唯一的实例给准备好了，在其他的代码种即使是有人搞错了直接new一个新对象，也不会出现错误
如上图的代码，结果打印出来是true，证明我们两次获取的是同一个对象，也就说明了Singleton类的对象是唯一的
上述代码，称为”饿汉模式“，是单例模式中一种简单的写法，所谓的“饿”形容非常的迫切，实例是在类被加载的时候就被创建了，创建的时机非常的早，相当于程序一启动，实例就创建了，就用“饿汉”来形容创建的实际非常的早，非常的迫切
能不能用反射调用到这个构造方法？
用反射是可以的，反射属于非常规手段，但是用枚举实现的单例模式是不能用反射破解的
懒汉模式
创建实例的实际不一样了，创建实例的机会会更晚，只有第一次使用的时候才会创建实例
“懒”这个词不是贬义词，而是褒义词，我们的社会进步，效率生产力提高其实是因为“懒”，所以在计算机里“懒”通常代表着更高的效率
比如有有一个非常大的文件(10G)，如果现在又一个编辑器想要打开这个文件的话，如果按照“饿汉”的方式就是一次性的将10G的文件加载到内存，然后再进行统一的展示，一次性加载10G的数据就会很耗费时间，而且一次性加载了这么多的数据，用户一次性也看不完，如果是按照“懒汉”的方式来的话，编辑器只会先读取一小部分的数据，比如说10KB，先把这些展示给用户，之后用户通过翻页等操作，再继续读取后面的数据，加载10KB的数据就是一瞬间事情
懒汉模式的代码如上，但是此时这个代码里面还有很多问题，我们下一篇文章将会讲到