auto_answer_个人页

加号 “+”String contact() 方法StringUtils.join() 方法StringBuffer append() 方法StringBuilder append() 方法

Java类加载器的作用就是在运行时加载类。Java类加载器基于三个机制：委托、可见性和单一性。委托机制是指将加载一个类的请求交给父类加载器，如果这个父类加载器不能够找到或者加载这个类，那么再加载它。可见性的原理是子类的加载器可以看见所有的父类加载器加载的类，而父类加载器看不到子类加载器加载的类。单一性原理是指仅加载一个类一次，这是由委托机制确保子类加载器不会再次加载父类加载器加载过的类。正确理解类加载器能够帮你解决NoClassDefFoundError和java.lang.ClassNotFoundException，因为它们和类的加载相关。类加载器通常也是比较高级的Java面试中的重要考题，Java类加载器和工作原理以及classpath如何运作的经常被问到。Java面试题中也经常出现“一个类是否能被两个不同类加载器加载”这样的问题。这篇教程中，我们将学到类加载器是什么，它的工作原理以及一些关于类加载器的知识点。 什么是类加载器类加载器是一个用来加载类文件的类。Java源代码通过javac编译器编译成类文件。然后JVM来执行类文件中的字节码来执行程序。类加载器负责加载文件系统、网络或其他来源的类文件。有三种默认使用的类加载器：Bootstrap类加载器、Extension类加载器和System类加载器（或者叫作Application类加载器）。每种类加载器都有设定好从哪里加载类。 Bootstrap类加载器负责加载rt.jar中的JDK类文件，它是所有类加载器的父加载器。Bootstrap类加载器没有任何父类加载器，如果你调用String.class.getClassLoader()，会返回null，任何基于此的代码会抛出NUllPointerException异常。Bootstrap加载器被称为初始类加载器。而Extension将加载类的请求先委托给它的父加载器，也就是Bootstrap，如果没有成功加载的话，再从jre/lib/ext目录下或者java.ext.dirs系统属性定义的目录下加载类。Extension加载器由sun.misc.Launcher$ExtClassLoader实现。第三种默认的加载器就是System类加载器（又叫作Application类加载器）了。它负责从classpath环境变量中加载某些应用相关的类，classpath环境变量通常由-classpath或-cp命令行选项来定义，或者是JAR中的Manifest的classpath属性。Application类加载器是Extension类加载器的子加载器。通过sun.misc.Launcher$AppClassLoader实现。除了Bootstrap类加载器是大部分由C来写的，其他的类加载器都是通过java.lang.ClassLoader来实现的。 总结一下，下面是三种类加载器加载类文件的地方： 1) Bootstrap类加载器 – JRE/lib/rt.jar 2) Extension类加载器 – JRE/lib/ext或者java.ext.dirs指向的目录 3) Application类加载器 – CLASSPATH环境变量, 由-classpath或-cp选项定义,或者是JAR中的Manifest的classpath属性定义. 类加载器的工作原理我之前已经提到过了，类加载器的工作原理基于三个机制：委托、可见性和单一性。这一节，我们来详细看看这些规则，并用一个实例来理解工作原理。下面显示的是类加载器使用委托机制的工作原理。 委托机制当一个类加载和初始化的时候，类仅在有需要加载的时候被加载。假设你有一个应用需要的类叫作Abc.class，首先加载这个类的请求由Application类加载器委托给它的父类加载器Extension类加载器，然后再委托给Bootstrap类加载器。Bootstrap类加载器会先看看rt.jar中有没有这个类，因为并没有这个类，所以这个请求由回到Extension类加载器，它会查看jre/lib/ext目录下有没有这个类，如果这个类被Extension类加载器找到了，那么它将被加载，而Application类加载器不会加载这个类；而如果这个类没有被Extension类加载器找到，那么再由Application类加载器从classpath中寻找。记住classpath定义的是类文件的加载目录，而PATH是定义的是可执行程序如javac，java等的执行路径。 可见性机制根据可见性机制，子类加载器可以看到父类加载器加载的类，而反之则不行。所以下面的例子中，当Abc.class已经被Application类加载器加载过了，然后如果想要使用Extension类加载器加载这个类，将会抛出java.lang.ClassNotFoundException异常。 1234567891011121314151617181920212223242526272829package test; import java.util.logging.Level; import java.util.logging.Logger; /** * Java program to demonstrate How ClassLoader works in Java, * in particular about visibility principle of ClassLoader. * * @author Javin Paul */ public class ClassLoaderTest { public static void main(String args[]) { try { //printing ClassLoader of this class System.out.println('ClassLoaderTest.getClass().getClassLoader() : ' + ClassLoaderTest.class.getClassLoader()); //trying to explicitly load this class again using Extension class loader Class.forName('test.ClassLoaderTest', true , ClassLoaderTest.class.getClassLoader().getParent()); } catch (ClassNotFoundException ex) { Logger.getLogger(ClassLoaderTest.class.getName()).log(Level.SEVERE, null, ex); } } } 输出: 12345678910111213ClassLoaderTest.getClass().getClassLoader() : sun.misc.Launcher$AppClassLoader@601bb116/08/2012 2:43:48 AM test.ClassLoaderTest mainSEVERE: nulljava.lang.ClassNotFoundException: test.ClassLoaderTest at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at sun.misc.Launcher$ExtClassLoader.findClass(Launcher.java:229) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:247) at test.ClassLoaderTest.main(ClassLoaderTest.java:29) 单一性机制根据这个机制，父加载器加载过的类不能被子加载器加载第二次。虽然重写违反委托和单一性机制的类加载器是可能的，但这样做并不可取。你写自己的类加载器的时候应该严格遵守这三条机制。 如何显式的加载类Java提供了显式加载类的API：Class.forName(classname)和Class.forName(classname, initialized, classloader)。就像上面的例子中，你可以指定类加载器的名称以及要加载的类的名称。类的加载是通过调用java.lang.ClassLoader的loadClass()方法，而loadClass()方法则调用了findClass()方法来定位相应类的字节码。在这个例子中Extension类加载器使用了java.net.URLClassLoader，它从JAR和目录中进行查找类文件，所有以”/”结尾的查找路径被认为是目录。如果findClass()没有找到那么它会抛出java.lang.ClassNotFoundException异常，而如果找到的话则会调用defineClass()将字节码转化成类实例，然后返回。 什么地方使用类加载器类加载器是个很强大的概念，很多地方被运用。最经典的例子就是AppletClassLoader，它被用来加载Applet使用的类，而Applets大部分是在网上使用，而非本地的操作系统使用。使用不同的类加载器，你可以从不同的源地址加载同一个类，它们被视为不同的类。J2EE使用多个类加载器加载不同地方的类，例如WAR文件由Web-app类加载器加载，而EJB-JAR中的类由另外的类加载器加载。有些服务器也支持热部署，这也由类加载器实现。你也可以使用类加载器来加载数据库或者其他持久层的数据。

一、Java内存分配     Java虚拟机在执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据区域。这些区域存储不同类型的数据，这些区域的内存分配和销毁的时间也不同，有的区域随着虚拟机进程的启动而存在，有些区域则是依赖用户线程的启动和结束而建立和销毁。根据《Java虚拟机规范（第2版）》的规定，Java虚拟机管理的内存包括五个运行时数据区域，如下图所示：      1、方法区     方法区（Method Area）是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息（包括类的名称、方法信息、成员变量信息）、常量、静态变量、以及编译器编译后的代码等数据。当方法区无法满足内存分配需求时，将抛出OutOfMemeryError异常。     运行时常量池（Runtime Constant Pool）是方法区的一部分,此区域会在两种情况下存储数据。     （1）class文件的常量池中的数据     class文件中的常量池用于存放编译期生成的各种字面值和常量，这部分内容在类被加载后存放到方法区的运行时常量池中。     字面值：private String name='zhangSan'；private int age = 23+3；     常量：private final String TAG = 'MainActivity'；private final int age = 26;     （2）运行期间生成的常量     运行时常量池相对于class文件常量池的另外一个重要特征是具备动态性，Java语言并不要求常量一定只能在编译期产生，也就是并非预置入class文件中常量池的内容才能进入方法区运行时常量池，运行期间也可能将新的常量放入池中，这种特性被开发人员利用得比较多的便是String类的intern()方法。String str = 'abc'.intern();当运行时常量池中存在字符串'abc时，将该字符串的引用返回，赋值给str，否则创建字符串'abc'，加入运行时常量池中，并返回引用赋值给str。既然运行时常量池是方法区的一部分，自然会受到方法区内存的限制，当常量池无法再申请到内存时会抛出OutOfMemoryError异常。 2、虚拟机栈     虚拟机栈是线程私有的内存空间，每个线程都有一个线程栈，每个方法被执行时都会创建一个栈帧，方法执行完成，栈帧弹出，线程运行结束，线程栈被回收。虚拟机栈就是Java中的方法执行的内存模型，每个方法在执行的同时都会创建一个栈帧，这个栈帧用于存储局部变量表、操作数栈、指向当前方法所属的类的运行时常量池的引用、方法返回地址等信息，每个方法从调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。局部变量表用来存储方法中的局部变量，包括方法中声明的变量以及函数形参。对于基本数据类型的变量，则直接存储它的值，对于引用类型的变量，则存的是指向对象的引用。局部变量表的大小在编译器就可以确定其大小，并且在程序执行期间局部变量表的大小是不会改变的。程序中的所有计算过程都是在借助于操作数栈来完成的。指向运行时常量池的引用，因为在方法执行的过程中有可能需要用到类中的常量，所以必须要有一个引用指向当前方法所属的类的运行时常量池。方法返回地址，当一个方法执行完毕之后，要返回之前调用它的地方，因此在栈帧中必须保存一个方法返回地址。     在Java虚拟机规范中，对这个区域规定了两种异常状况：如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常；如果虚拟机栈可以动态扩展（当前大部分的Java虚拟机都可动态扩展，只不过Java虚拟机规范中也允许固定长度的虚拟机栈），当扩展时无法申请到足够的内存时会抛出OutOfMemoryError异常。 3、本地方法栈     本地方法栈也是线程私有的内存空间，本地方法栈与Java栈所发挥的作用是非常相似的，它们之间的区别不过是Java栈执行Java方法，本地方法栈执行的是本地方法，有的虚拟机直接把本地方法栈和虚拟机栈合二为一。 4、堆     Java堆是Java虚拟机所管理的内存中最大的一块，在虚拟机启动时创建，此内存区域的目的就是存放对象实例，几乎所有的对象实例都在这里分配内存。从内存分配的角度来看，线程共享的Java堆中可能划分出多个线程私有的分配缓冲区(TLAB)。Java堆可以处于物理上不连续的内存空间，只要逻辑上连续即可，在实现上，既可以实现固定大小的，也可以是扩展的。如果堆中没有足够的内存分配给实例，并且堆也无法再拓展时，将会抛出OutOfMemeryError异常。     堆是运行时动态分配内存，对象在没有引用变量指向它的时候，才变成垃圾，但是仍然占着内存，在程序空闲的时候（没有工作线程运行，GC线程优先级最低）或者堆内存不足的时候（GC线程被触发），被垃圾回收器释放掉，由于要在运行时动态分配内存，存取速度较慢。 5、程序计数器     程序计数器的作用可以看做是当前线程所执行的字节码的行号指示。字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。由于Java虚拟机的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现的，在任何一个确定的时刻，一个处理器（对于多核处理器来说是一个内核）只会执行一条线程中的指令。因此，为了线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器，各条线程之间的计数器互不影响，独立存储，我们称这类内存区域为线程私有的内存。如果线程正在执行的是一个Java方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址；如果正在执行的是Natvie方法，这个计数器值则为空。 二、Java内存回收     对于虚拟机栈空间，当方法调用结束后，基本类型变量、引用类型变量、形参占据的空间会被自动释放，但引用类型指向的对象在堆中，堆中的无用内存由垃圾回收线程回收，GC线程优先级最低，只有当没有工作线程存在时GC线程才会执行，或者堆空间不足时会自动触发GC线程工作。除了回收内存，GC线程还负责整理堆中的碎片。 1、四种引用类型     Java中的对象引用分为四种，强引用类型、软引用类型、弱引用类型、虚引用类型。Java中提供这四种引用类型主要有两个目的：第一是可以让程序员通过代码的方式决定某些对象的生命周期；第二是有利于JVM进行垃圾回收。使用软引用和弱引用可以有效的避免oom。软引用关联的对象，只有软引用关联时，才可回收，如果有强引用同时关联，不会回收对象占用的内存，弱引用也如此。 （1）强引用     强引用是使用最普遍的引用，类似Object obj = new Object()、String str = 'hello'。如果一个对象具有强引用，那垃圾回收器绝不会回收它。当内存空间不足，Java虚拟机宁愿抛出OutOfMemoryError错误，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足的问题。 （2）软引用（SoftReference）     软引用是用来描述一些有用但并不是必需的对象，在Java中用java.lang.ref.SoftReference类来表示，如果内存空间足够，垃圾回收器就不会回收它；如果内存空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。软引用通常用于网页缓存、图片缓存，防止内存溢出，在内存充足的时候，缓存对象会一直存在，在内存不足的时候，缓存对象占用的内存会被垃圾收集器回收。使用示例： public void testSoftReference() { Map> imagesCache = new HashMap>(); Bitmap bitmap = getBitmap(); SoftReference image1 = new SoftReference(bitmap); imagesCache.put('image1',image1); SoftReference result_SoftReference = imagesCache.get('image1'); Bitmap result_Bitmap = result_SoftReference .get(); } import java.lang.ref.SoftReference; public class Main { public static void main(String[] args) { SoftReference sr = new SoftReference(new String('hello')); System.out.println(sr.get()); } } （3）弱引用（WeakReference）     弱引用也是用来描述非必需对象的，但是它的强度比软引用更弱一些，在java中用java.lang.ref.WeakReference类来表示。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象，不过由于垃圾回收器是一个优先级很低的线程，因此不一定会很快发现那些只具有弱引用的对象。弱引用可以用于：单例类持有一个activity引用时，会造成内存泄露，把activity声明为弱引用，在activity销毁后，垃圾收集器扫描到activity对象时，会回收activity对象的内存。使用示例： public class SingleTon1 { private static final SingleTon1 mInstance = null; private WeakReference mContext; private SingleTon1(WeakReference context) { mContext = context; } public static SingleTon1 getInstance(WeakReference context) { if (mInstance == null) { synchronized (SingleTon1.class) { if (mInstance == null) { mInstance = new SingleTon1(context); } } } return mInstance; } } public class MyActivity extents Activity { public void onCreate (Bundle savedInstanceState){ super.onCreate(savedInstanceState); setContentView(R.layout.main); SingleTon1 singleTon1 = SingleTon1.getInstance(new WeakReference(this)); } }import java.lang.ref.WeakReference; public class Main { public static void main(String[] args) { WeakReference sr = new WeakReference(new String('hello')); System.out.println(sr.get()); System.gc(); //通知JVM的gc进行垃圾回收 System.out.println(sr.get()); } } 输出结果： hellonull     第二个输出结果是null，这说明只要JVM进行垃圾回收，被弱引用关联的对象必定会被回收掉。不过要注意的是，这里所说的被弱引用关联的对象是指只有弱引用与之关联，如果存在强引用同时与之关联，则进行垃圾回收时也不会回收该对象（软引用也是如此）。 （4）虚引用     虚引用和软引用、弱引用不同，它并不影响对象的生命周期，也无法通过虚引用来取得一个对象实例，在java中用java.lang.ref.PhantomReference类表示。如果一个对象与虚引用关联，则跟没有引用与之关联一样，在任何时候都可能被垃圾回收器回收。虚引用必须和引用队列（ReferenceQueue）联合使用，如下： import java.lang.ref.PhantomReference;import java.lang.ref.ReferenceQueue; public class Main { public static void main(String[] args) { ReferenceQueue queue = new ReferenceQueue(); PhantomReference pr = new PhantomReference(new String('hello'), queue); System.out.println(pr.get()); } } 2、垃圾回收算法 （1）标记-清除（Mark-Sweep）    标记-清除（Mark-Sweep）算法，分为标记和清除两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收掉所有被标记的对象。 标记-清除算法主要问题是：1、效率问题，标记和清除过程的效率很低2、空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致，当程序在以后的运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另一次垃圾收集 （2）复制（Copying）算法     复制算法，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对其中的一块进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。 复制算法的主要问题是：1、复制算法将内存缩小为原来的一半，过于浪费2、对象存活率较高时就要执行较多的复制操作，造成频繁GC,效率将会变低 （3）标记-整理（Mark-Compact）     标记-整理算法的标记过程仍然与标记-清除算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存，这样连续的内存空间就比较多了。     如上图所示，所有存活的对象依次向左上角移动，（0,4）移动到（0,2），（1,0）移动到（0,3），依次类推，当所有的存活对象移动完成后，把剩余的所有空间清空，也就是清空（1,1）后的所有空间。 （4）分代回收（generational collection） 程序创建的大部分对象的生命周期都很短，只有一小部分对象的生命周期比较长，根据这样的规律，一般把Java堆分为Young Generation（新生代），Old Generation（老年代）和Permanent Generation（持久代），上面几种算法是通过分代回收混合在一起的，这样就可以根据各个年代的特点采用最适当的回收算法。 （1）新生代     在新生代中，有一个叫Eden Space的空间，主要是用来存放新生的对象，还有两个Survivor Spaces（from、to）， 这两个区域大小相等，相当于copying算法中的两个区域，它们用来存放每次垃圾回收后存活下来的对象。在新生代中，垃圾回收一般用Copying的算法，速度快。     当新建对象无法放入eden区时，将触发minor collection（minorGC 是清理新生代的GC线程，eden的清理，from、to的清理都由MinorGC完成），将eden区与from区的存活对象复制到to区，经过一次垃圾回收，eden区和from区清空，to区中则紧密的存放着存活对象；当eden区再次满时，minor collection将eden区和to区的存活对象复制到from区，eden区和to区被清空，from区存放eden区和to区的存活对象，就这样from区和to区来回切换。如果进行minor collection的时候，发现to区放不下，则将eden区和from区的部分对象放入成熟代。另一方面，即使to区没有满，JVM依然会移动世代足够久远的对象到成熟代。 （2）成熟代     在成熟代中主要存放应用程序中生命周期长的内存对象，垃圾回收一般用mark-compact的算法，速度慢些，但减少内存要求。如果成熟代放满对象，无法从新生代移入新的对象，那么将触发major collection（major GC清理整合OldGen的内存空间）。 （3）永久代    在永久代中，主要用来放JVM自己的反射对象，比如类对象、方法对象、成员变量对象、构造方法对象等。     此外，垃圾回收一般是在程序空闲的时候（没有工作线程，GC线程优先级较低）或者堆内存不足的时候自动触发，也可以调用System.gc()主动的通知Java虚拟机进行垃圾回收，但这只是个建议，Java虚拟机不一定马上执行，启动时机的选择由JVM决定，并且取决于堆内存中Eden区是否可用 作者：喜六六 来源：CSDN 原文：https://blog.csdn.net/qq_29078329/article/details/78929457 版权声明：本文为博主原创文章，转载请附上博文链接！

1，架构师是什么？要想往架构师的方向发展首先要知道架构师是什么？架构师是一个既需要掌控整体又需要洞悉局部瓶颈并依据具体的业务场景给出解决方案的团队领导型人物。一个架构师得需要足够的想像力,能把各种目标需求进行不同维度的扩展，为目标客户提供更为全面的需求清单。架构师在软件开发的整个过程中起着很重要的作用。说的详细一些，架构师就是确认和评估系统需求，给出开发规范，搭建系统实现的核心构架，并澄清技术细节、扫清主要难点的技术人员。主要着眼于系统的“技术实现”。2，架构师的任务架构师的主要任务不是从事具体的软件程序的编写，而是从事更高层次的开发构架工作。他必须对开发技术非常了解，并且需要有良好的组织管理能力。可以这样说，一个架构师工作的好坏决定了整个软件开发项目的成败。在成为Java架构师之前，应当先成为Java工程师。熟练使用各种框架，并知道它们实现的原理。jvm虚拟机原理、调优，懂得jvm能让你写出性能更好的代码；池技术，什么对象池，连接池，线程池……Java反射技术，写框架必备的技术，遇到有严重的性能问题，替代方案java字节码技术；nio，没什么好说的，值得注意的是'直接内存'的特点，使用场景；java多线程同步异步；java各种集合对象的实现原理，了解这些可以让你在解决问题时选择合适的数据结构，高效的解决问题，比如hashmap的实现原理，好多五年以上经验的人都弄不清楚，还有为什扩容时有性能问题？不弄清楚这些原理，就写不出高效的代码，还会认为自己做的很对；总之一句话，越基础的东西越重要，很多人认为自己会用它们写代码了，其实仅仅是知道如何调用api而已,离会用还差的远。如果你立志做架构，首先打好基础，从最底层开始。然后发展到各种技术和语言，什么都要懂两点，要全面且不肤浅。为什么不是懂一点？你要看得透彻，必须尽量深入一些。别人懂一点，你要做架构师，必须再多懂一点。比如你发现golang很流行，别人可能写一个helloworld就说自己玩过golang，但你至少要尝试写一个完整的应用。不肯下苦功，如何高人一头？另外你要非常深入地了解至少一门语言，如果你的目标是java，就学到极致，作为敲门砖，先吃饱了才能谈理想。3，架构师都是从码农过来的而Java学到极致势必涉及到设计模式，算法和数据结构，多线程，文件及网络IO，数据库及ORM，不一而足。这些概念放之一切语言都适用。先精一门，为全面且不肤浅打基础。另外就是向有经验的架构师学习，和小伙伴们讨论辩论争论。其实最重要的能力就是不断学习。在思考新的技术是否能更好地解决你们遇到的问题之前，你首先得知道并了解新的技术。架构师都是从码农过来的，媳妇熬成婆。千万不要成为不写代码的架构师，有些公司专门产不写技术的架构师。所谓架构师，只是功底深厚的程序员而已。个人认为应该扎扎实实学习基础知识，学习各种规范，架构，需要广泛的知识面，懂的东西越多视野越开阔，设计的东西当然会越好越全面。成为架构师需要时间的积累的，不但要知其然还要知其所以然。平时的一点一滴你感觉不到特别用处，但某天你会发现所有东西都没有白学的。4，架构师知识体系下面是我总结多年经验开发的架构师知识体系一、分布式架构架构分布式的英文（ Distributed computing 分布式计算技术）的应用和工具，成熟目前的技术包括 J2EE，CORBA 和 .NET（DCOM），这些技术牵扯的内容非常广，相关的书籍也非常多。本文不介绍这些技术的内容，也没有涉及这些技术的细节，只是从各种分布式系统平台产生的背景和在软件开发中应用的情况来探讨它们的主要异同。分布式系统是一个古老而宽泛的话题，而近几年因为“大数据”概念的兴起，又焕发出了新的青春与活力。除此之外，分布式系统也是一门理论模型与工程技法。并重的学科内容相比于机器学习这样的研究方向，学习分布式系统的同学往往会感觉：“入门容易，深入难”的确，学习分布式系统几乎不需要太多数学知识。分布式系统是一个复杂且宽泛的研究领域，学习一两门在线课程，看一两本书可能都是不能完全覆盖其所有内容的。总的来说，分布式系统要做的任务就是把多台机器有机的组合，连接起来，让其协同完成一件任务，可以是计算任务，也可以是存储任务。如果一定要给近些年的分布式系统研究做一个分类的话，我个人认为大概可以包括三大部分：分布式存储系统分布式计算系统分布式管理系统二、微服务当前微服务很热，大家都号称在使用微服务架构，但究竟什么是微服务架构？微服务架构是不是发展趋势？对于这些问题，我们都缺乏清楚的认识。为解决单体架构下的各种问题，微服务架构应运而生。与其构建一个臃肿庞大，难以驯服的怪兽，还不如及早将服务拆分。微服务的核心思想便是服务拆分与解耦，降低复杂性。微服务强调将功能合理拆解，尽可能保证每个服务的功能单一，按照单一责任原则（Single Responsibility Principle）明确角色。将各个服务做轻，从而做到灵活，可复用，亦可根据各个服务自身资源需求，单独布署，单独作横向扩展。微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的类上应用很多 SOLID 原则。微服务架构是个很有趣的概念，它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。概念：把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。定义：围绕业务领域组件来创建应用，这些应用可独立地进行开发，管理和迭代在分散的组件中使用云架构和平台式部署，管理和服务功能，使产品交付变得更加简单。本质：用一些功能比较明确，业务比较精练的服务去解决更大，更实际的问题。三、源码分析从字面意义上来讲，源文件的英文指一个文件，指源代码的集合。源代码则是一组具有特定意义的可以实现特定功能的字符（程序开发代码）。源码分析是一种临界知识，掌握了这种临界知识，能不变应万变，源码分析对于很多人来说很枯燥，生涩难懂。源码阅读，我觉得最核心有三点：技术基础+强烈的求知欲+耐心。我认为是阅读源码的最核心驱动力我见到绝大多数程序员，对学习的态度，基本上就是这几个层次（很偏激哦）：1，只关注项目本身，不懂就百度一下。2，除了做好项目，还会阅读和项目有关的技术书籍，看维基百科。3，除了阅读和项目相关的书外，还会阅读IT行业的书，比如学的Java的时，还会去了解函数语言，如LISP。4，找一些开源项目看看，大量试用第三方框架，还会写写演示。5，阅读基础框架，J2EE 规范，调试服务器内核。大多数程序都是第1种，到第5种不光需要浓厚的兴趣，还需要勇气：？我能读懂吗其实，你能够读懂的耐心，真的很重要。因为你极少看到阅读源码的指导性文章或书籍，也没有人要求或建议你读。你读的过程中经常会卡住，而一卡主可能就陷进了迷宫这时，你需要做的，可能是暂时中断一下，再从外围看看它：如API结构，框架的设计图。四、工具使用工欲善其事必先利其器，工具对 Java 的的程序员的重要性不言而喻现在有很多库，实用工具和程序任的 Java 的开发人员选择。下图列出的工具都是程序员必不可少的工具五、性能优化不管是应付前端面试还是改进产品体验，性能优化都是躲不开的话题。优化的目的是让用户有“快”的感受，那如何让用户感受到快呢？加载速度真的很快，用户打开输入网址按下回车立即看到了页面加载速度并没有变快，但用户感觉你的网站很快性能优化取决于多个因素，包括垃圾收集，虚拟机和底层操作系统（OS）设置。有多个工具可供开发人员进行分析和优化时使用，你可以通过阅读爪哇工具的源代码优化和分析来学习和使用它们。必须要明白的是，没有两个应用程序可以使用相同的优化方式，也没有完美的优化的 Java 应用程序的参考路径。使用最佳实践并且坚持采用适当的方式处理性能优化。想要达到真正最高的性能优化，你作为一个 Java 的开发人员，需要对 Java 的虚拟机（JVM）和底层操作系统有正确的理解。性能优化，简而言之，就是在不影响系统运行正确性的前提下，使之运行地更快，完成特定功能所需的时间更短。性能问题永远是永恒的主题之一，而优化则更需要技巧。Java程序员如何学习才能快速入门并精通呢？当真正开始学习的时候难免不知道从哪入手，导致效率低下影响继续学习的信心。但最重要的是不知道哪些技术需要重点掌握，学习时频繁踩坑，最终浪费大量时间，所以有一套实用的视频课程用来跟着学习是非常有必要的。为了让学习变得轻松、高效，今天给大家免费分享一套阿里架构师传授的一套教学资源。帮助大家在成为架构师的道路上披荆斩棘。这套视频课程详细讲解了（Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构）等这些成为架构师必备的内容！而且还把框架需要用到的各种程序进行了打包，根据基础视频可以让你轻松搭建分布式框架环境，像在企业生产环境一样进行学习和实践。

一、Lambda表达式 Lambda表达式可以说是Java 8最大的卖点，她将函数式编程引入了Java。Lambda允许把函数作为一个方法的参数，或者把代码看成数据。 一个Lambda表达式可以由用逗号分隔的参数列表、–>符号与函数体三部分表示。例如： Arrays.asList( 'p', 'k', 'u','f', 'o', 'r','k').forEach( e -> System.out.println( e ) ); 1 Arrays.asList( 'p', 'k', 'u','f', 'o', 'r','k').forEach( e -> System.out.println( e ) ); 为了使现有函数更好的支持Lambda表达式，Java 8引入了函数式接口的概念。函数式接口就是只有一个方法的普通接口。java.lang.Runnable与java.util.concurrent.Callable是函数式接口最典型的例子。为此，Java 8增加了一种特殊的注解@FunctionalInterface： 1 @FunctionalInterface2 public interface Functional {3 void method();4 }二、接口的默认方法与静态方法 我们可以在接口中定义默认方法，使用default关键字，并提供默认的实现。所有实现这个接口的类都会接受默认方法的实现，除非子类提供的自己的实现。例如： 1 public interface DefaultFunctionInterface {2 default String defaultFunction() {3 return 'default function';4 }5 }我们还可以在接口中定义静态方法，使用static关键字，也可以提供实现。例如： 1 public interface StaticFunctionInterface {2 static String staticFunction() {3 return 'static function';4 }5 }接口的默认方法和静态方法的引入，其实可以认为引入了C＋＋中抽象类的理念，以后我们再也不用在每个实现类中都写重复的代码了。 三、方法引用 通常与Lambda表达式联合使用，可以直接引用已有Java类或对象的方法。一般有四种不同的方法引用： 构造器引用。语法是Class::new，或者更一般的Class::new，要求构造器方法是没有参数； 静态方法引用。语法是Class::static_method，要求接受一个Class类型的参数； 特定类的任意对象方法引用。它的语法是Class::method。要求方法是没有参数的； 特定对象的方法引用，它的语法是instance::method。要求方法接受一个参数，与3不同的地方在于，3是在列表元素上分别调用方法，而4是在某个对象上调用方法，将列表元素作为参数传入； 四、重复注解 在Java 5中使用注解有一个限制，即相同的注解在同一位置只能声明一次。Java 8引入重复注解，这样相同的注解在同一地方也可以声明多次。重复注解机制本身需要用@Repeatable注解。Java 8在编译器层做了优化，相同注解会以集合的方式保存，因此底层的原理并没有变化。 五、扩展注解的支持 Java 8扩展了注解的上下文，几乎可以为任何东西添加注解，包括局部变量、泛型类、父类与接口的实现，连方法的异常也能添加注解。 六、Optional Java 8引入Optional类来防止空指针异常，Optional类最先是由Google的Guava项目引入的。Optional类实际上是个容器：它可以保存类型T的值，或者保存null。使用Optional类我们就不用显式进行空指针检查了。 七、Stream Stream API是把真正的函数式编程风格引入到Java中。其实简单来说可以把Stream理解为MapReduce，当然Google的MapReduce的灵感也是来自函数式编程。她其实是一连串支持连续、并行聚集操作的元素。从语法上看，也很像linux的管道、或者链式编程，代码写起来简洁明了，非常酷帅！ 八、Date/Time API (JSR 310) Java 8新的Date-Time API (JSR 310)受Joda-Time的影响，提供了新的java.time包，可以用来替代 java.util.Date和java.util.Calendar。一般会用到Clock、LocaleDate、LocalTime、LocaleDateTime、ZonedDateTime、Duration这些类，对于时间日期的改进还是非常不错的。 九、JavaScript引擎Nashorn Nashorn允许在JVM上开发运行JavaScript应用，允许Java与JavaScript相互调用。 十、Base64 在Java 8中，Base64编码成为了Java类库的标准。Base64类同时还提供了对URL、MIME友好的编码器与解码器。 除了这十大新特性之外，还有另外的一些新特性： 更好的类型推测机制：Java 8在类型推测方面有了很大的提高，这就使代码更整洁，不需要太多的强制类型转换了。 编译器优化：Java 8将方法的参数名加入了字节码中，这样在运行时通过反射就能获取到参数名，只需要在编译时使用-parameters参数。 并行（parallel）数组：支持对数组进行并行处理，主要是parallelSort()方法，它可以在多核机器上极大提高数组排序的速度。 并发（Concurrency）：在新增Stream机制与Lambda的基础之上，加入了一些新方法来支持聚集操作。 Nashorn引擎jjs：基于Nashorn引擎的命令行工具。它接受一些JavaScript源代码为参数，并且执行这些源代码。 类依赖分析器jdeps：可以显示Java类的包级别或类级别的依赖。 JVM的PermGen空间被移除：取代它的是Metaspace（JEP 122）。

Java 11 新特性官网公开的 17 个 JEP（JDK Enhancement Proposal 特性增强提议）：181: Nest-Based Access Control（基于嵌套的访问控制）309: Dynamic Class-File Constants（动态的类文件常量）315: Improve Aarch64 Intrinsics（改进 Aarch64 Intrinsics）318: Epsilon: A No-Op Garbage Collector（Epsilon 垃圾回收器，又被称为'No-Op（无操作）'回收器）320: Remove the Java EE and CORBA Modules（移除 Java EE 和 CORBA 模块，JavaFX 也已被移除）321: HTTP Client (Standard)323: Local-Variable Syntax for Lambda Parameters（用于 Lambda 参数的局部变量语法）324: Key Agreement with Curve25519 and Curve448（采用 Curve25519 和 Curve448 算法实现的密钥协议）327: Unicode 10328: Flight Recorder（飞行记录仪）329: ChaCha20 and Poly1305 Cryptographic Algorithms（实现 ChaCha20 和 Poly1305 加密算法）330: Launch Single-File Source-Code Programs（启动单个 Java 源代码文件的程序）331: Low-Overhead Heap Profiling（低开销的堆分配采样方法）332: Transport Layer Security (TLS) 1.3（对 TLS 1.3 的支持）333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)（ZGC：可伸缩的低延迟垃圾回收器，处于实验性阶段）335: Deprecate the Nashorn JavaScript Engine（弃用 Nashorn JavaScript 引擎）336: Deprecate the Pack200 Tools and API（弃用 Pack200 工具及其 API）

MQTT协议 MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）最早是IBM开发的一个即时通讯协议，MQTT协议是为大量计算能力有限且工作在低带宽、不可靠网络的远程传感器和控制设备通讯而设计的一种协议。 MQTT协议的优势是可以支持所有平台，它几乎可以把所有的联网物品和互联网连接起来。 它具有以下主要的几项特性：1、使用发布/订阅消息模式，提供一对多的消息发布和应用程序之间的解耦；2、消息传输不需要知道负载内容；3、使用 TCP/IP 提供网络连接；4、有三种消息发布的服务质量：QoS 0：“最多一次”，消息发布完全依赖底层 TCP/IP 网络。分发的消息可能丢失或重复。例如，这个等级可用于环境传感器数据，单次的数据丢失没关系，因为不久后还会有第二次发送。QoS 1：“至少一次”，确保消息可以到达，但消息可能会重复。QoS 2：“只有一次”，确保消息只到达一次。例如，这个等级可用在一个计费系统中，这里如果消息重复或丢失会导致不正确的收费。5、小型传输，开销很小（固定长度的头部是 2 字节），协议交换最小化，以降低网络流量；6、使用 Last Will 和 Testament 特性通知有关各方客户端异常中断的机制；在MQTT协议中，一个MQTT数据包由：固定头（Fixed header）、 可变头（Variable header）、 消息体（payload）三部分构成。MQTT的传输格式非常精小，最小的数据包只有2个bit，且无应用消息头。下图是MQTT为可靠传递消息的三种消息发布服务质量 发布/订阅模型允许MQTT客户端以一对一、一对多和多对一方式进行通讯。 下图是MQTT的发布／订阅消息模式 CoAP协议 CoAP是受限制的应用协议(Constrained Application Protocol)的代名词。由于目前物联网中的很多设备都是资源受限型的，所以只有少量的内存空间和有限的计算能力，传统的HTTP协议在物联网应用中就会显得过于庞大而不适用。因此，IETF的CoRE工作组提出了一种基于REST架构、传输层为UDP、网络层为6LowPAN（面向低功耗无线局域网的IPv6）的CoAP协议。 CoAP采用与HTTP协议相同的请求响应工作模式。CoAP协议共有4中不同的消息类型。CON——需要被确认的请求，如果CON请求被发送，那么对方必须做出响应。NON——不需要被确认的请求，如果NON请求被发送，那么对方不必做出回应。ACK——应答消息，接受到CON消息的响应。RST——复位消息，当接收者接受到的消息包含一个错误，接受者解析消息或者不再关心发送者发送的内容，那么复位消息将会被发送。 CoAP消息格式使用简单的二进制格式，最小为4个字节。 一个消息=固定长度的头部header + 可选个数的option + 负载payload。Payload的长度根据数据报长度来计算。 主要是一对一的协议 举个例子： 比如某个设备需要从服务器端查询当前温度信息。 请求消息（CON）： GET /temperature , 请求内容会被包在CON消息里面响应消息 (ACK)： 2.05 Content “22.5 C” ，响应内容会被放在ACK消息里面 CoAP与MQTT的区别 MQTT和CoAP都是行之有效的物联网协议，但两者还是有很大区别的，比如MQTT协议是基于TCP，而CoAP协议是基于UDP。从应用方向来分析，主要区别有以下几点： 1、MQTT协议不支持带有类型或者其它帮助Clients理解的标签信息，也就是说所有MQTT Clients必须要知道消息格式。而CoAP协议则相反，因为CoAP内置发现支持和内容协商，这样便能允许设备相互窥测以找到数据交换的方式。 2、MQTT是长连接而CoAP是无连接。MQTT Clients与Broker之间保持TCP长连接，这种情形在NAT环境中也不会产生问题。如果在NAT环境下使用CoAP的话，那就需要采取一些NAT穿透性手段。 3、MQTT是多个客户端通过中央代理进行消息传递的多对多协议。它主要通过让客户端发布消息、代理决定消息路由和复制来解耦消费者和生产者。MQTT就是相当于消息传递的实时通讯总线。CoAP基本上就是一个在Server和Client之间传递状态信息的单对单协议。 HTTP协议http的全称是HyperText Transfer Protocol，超文本传输协议，这个协议的提出就是为了提供和接收HTML界面，通过这个协议在互联网上面传出web的界面信息。 HTTP协议的两个过程，Request和Response，两个都有各自的语言格式，我们看下是什么。请求报文格式：(注意这里有个换行) 响应报文格式：(注意这里有个换行) 方法method：       这个很重要，比如说GET和POST方法，这两个是很常用的，GET就是获取什么内容，而POST就是向服务器发送什么数据。当然还有其他的，比如HTTP 1.1中还有：DELETE、PUT、CONNECT、HEAD、OPTIONS、TRACE等一共8个方法（HTTP Method历史：HTTP 0.9 只有GET方法；HTTP 1.0 有GET、POST、HEAD三个方法）。请求URL:       这里填写的URL是不包含IP地址或者域名的，是主机本地文件对应的目录地址，所以我们一般看到的就是“/”。版本version：       格式是HTTP/.这样的格式，比如说HTTP/1.1.这个版本代表的就是我们使用的HTTP协议的版本，现在使用的一般是HTTP/1.1状态码status:       状态码是三个数字，代表的是请求过程中所发生的情况，比如说200代表的是成功，404代表的是找不到文件。原因短语reason-phrase：       是状态码的可读版本，状态码就是一个数字，如果你事先不知道这个数字什么意思，可以先查看一下原因短语。首部header：       注意这里的header我们不是叫做头，而是叫做首部。可能有零个首部也可能有多个首部，每个首部包含一个名字后面跟着一个冒号，然后是一个可选的空格，接着是一个值，然后换行。实体的主体部分entity-body：       实体的主体部分包含一个任意数据组成的数据块，并不是所有的报文都包含实体的主体部分，有时候只是一个空行加换行就结束了。 下面我们举个简单的例子： 请求报文：GET /index.html HTTP/1.1    Accept: text/*Host: www.myweb.com 响应报文：HTTP/1.1 200 OKContent-type: text/plainContent-length: 3  HTTP与CoAP的区别 CoAP是6LowPAN协议栈中的应用层协议，基于REST（表述性状态传递）架构风格，支持与REST进行交互。通常用户可以像使用HTTP协议一样用CoAP协议来访问物联网设备。而且CoAP消息格式使用简单的二进制格式，最小为4个字节。HTTP使用报文格式对于嵌入式设备来说需要传输数据太多，太重，不够灵活。 XMPP协议 XMPP（可扩展通讯和表示协议）是一种基于可扩展标记语言（XML）的协议， 它继承了在XML环境中灵活的发展性。可用于服务类实时通讯、表示和需求响应服务中的XML数据元流式传输。XMPP以Jabber协议为基础，而Jabber是即时通讯中常用的开放式协议。   基本网络结构 XMPP中定义了三个角色，客户端，服务器，网关。通信能够在这三者的任意两个之间双向发生。 服务器同时承担了客户端信息记录，连接管理和信息的路由功能。网关承担着与异构即时通信系统 的互联互通，异构系统可以包括SMS（短信），MSN，ICQ等。基本的网络形式是单客户端通过 TCP/IP连接到单服务器，然后在之上传输XML。 功能 传输的是与即时通讯相关的指令。在以前这些命令要么用2进制的形式发送（比如QQ），要么用纯文本指令加空格加参数加换行符的方式发送（比如MSN）。而XMPP传输的即时通讯指令的逻辑与以往相仿，只是协议的形式变成了XML格式的纯文本。举个例子看看所谓的XML（标准通用标记语言的子集）流是什么样子的？客户端：123456to='example_com'xmlns='jabber:client'xmlns:stream='http_etherx_jabber_org/streams'version='1.0'>服务器：1234567from='example_com'id='someid'xmlns='jabber:client'xmlns:stream='http_etherx_jabber_org/streams'version='1.0'>工作原理XMPP核心协议通信的基本模式就是先建立一个stream，然后协商一堆安全之类的东西， 中间通信过程就是客户端发送XML Stanza，一个接一个的。服务器根据客户端发送的信息 以及程序的逻辑，发送XML Stanza给客户端。但是这个过程并不是一问一答的，任何时候 都有可能从一方发信给另外一方。通信的最后阶段是关闭流，关闭TCP/IP连接。  网络通信过程中数据冗余率非常高，网络流量中70% 都消耗在 XMPP 协议层了。对于物联网来说，大量计算能力有限且工作在低带宽、不可靠网络的远程传感器和控制设备，省电、省流量是所有底层服务的一个关键技术指标，XMPP协议看起来已经落后了。 SoAP协议 SoAP(简单对象访问协议)是交换数据的一种协议规范，是一种轻量的、简单的、 基于可扩展标记语言（XML）的协议，它被设计成在WEB上交换结构化的和固化的信息。  SOAP 可以和现存的许多因特网协议和格式结合使用，包括超文本传输协议（HTTP）， 简单邮件传输协议（SMTP），多用途网际邮件扩充协议（MIME）。它还支持从消息系统到 远程过程调用（RPC）等大量的应用程序。SOAP使用基于XML的数据结构和超文本传输协议 (HTTP)的组合定义了一个标准的方法来使用Internet上各种不同操作环境中的分布式对象。 总结： 从当前物联网应用发展趋势来分析，MQTT协议具有一定的优势。因为目前国内外主要的云计算服务商，比如阿里云、AWS、百度云、Azure以及腾讯云都一概支持MQTT协议。还有一个原因就是MQTT协议比CoAP成熟的要早，所以MQTT具有一定的先发优势。但随着物联网的智能化和多变化的发展，后续物联网应用平台肯定会兼容更多的物联网应用层协议。 作者：HFK_Frank 来源：CSDN 原文：https://blog.csdn.net/acongge2010/article/details/79142380 版权声明：本文为博主原创文章，转载请附上博文链接！

微服务 (MicroServices) 架构是当前互联网业界的一个技术热点，圈里有不少同行朋友当前有计划在各自公司开展微服务化体系建设，他们都有相同的疑问：一个微服务架构有哪些技术关注点 (technical concerns)？需要哪些基础框架或组件来支持微服务架构？这些框架或组件该如何选型？笔者之前在两家大型互联网公司参与和主导过大型服务化体系和框架建设，同时在这块也投入了很多时间去学习和研究，有一些经验和学习心得，可以和大家一起分享。 服务注册、发现、负载均衡和健康检查和单块 (Monolithic) 架构不同，微服务架构是由一系列职责单一的细粒度服务构成的分布式网状结构，服务之间通过轻量机制进行通信，这时候必然引入一个服务注册发现问题，也就是说服务提供方要注册通告服务地址，服务的调用方要能发现目标服务，同时服务提供方一般以集群方式提供服务，也就引入了负载均衡和健康检查问题。根据负载均衡 LB 所在位置的不同，目前主要的服务注册、发现和负载均衡方案有三种： 第一种是集中式 LB 方案，如下图 Fig 1，在服务消费者和服务提供者之间有一个独立的 LB，LB 通常是专门的硬件设备如 F5，或者基于软件如 LVS，HAproxy 等实现。LB 上有所有服务的地址映射表，通常由运维配置注册，当服务消费方调用某个目标服务时，它向 LB 发起请求，由 LB 以某种策略（比如 Round-Robin）做负载均衡后将请求转发到目标服务。LB 一般具备健康检查能力，能自动摘除不健康的服务实例。服务消费方如何发现 LB 呢？通常的做法是通过 DNS，运维人员为服务配置一个 DNS 域名，这个域名指向 LB。 Fig 1, 集中式 LB 方案 集中式 LB 方案实现简单，在 LB 上也容易做集中式的访问控制，这一方案目前还是业界主流。集中式 LB 的主要问题是单点问题，所有服务调用流量都经过 LB，当服务数量和调用量大的时候，LB 容易成为瓶颈，且一旦 LB 发生故障对整个系统的影响是灾难性的。另外，LB 在服务消费方和服务提供方之间增加了一跳 (hop)，有一定性能开销。 第二种是进程内 LB 方案，针对集中式 LB 的不足，进程内 LB 方案将 LB 的功能以库的形式集成到服务消费方进程里头，该方案也被称为软负载 (Soft Load Balancing) 或者客户端负载方案，下图 Fig 2 展示了这种方案的工作原理。这一方案需要一个服务注册表 (Service Registry) 配合支持服务自注册和自发现，服务提供方启动时，首先将服务地址注册到服务注册表（同时定期报心跳到服务注册表以表明服务的存活状态，相当于健康检查），服务消费方要访问某个服务时，它通过内置的 LB 组件向服务注册表查询（同时缓存并定期刷新）目标服务地址列表，然后以某种负载均衡策略选择一个目标服务地址，最后向目标服务发起请求。这一方案对服务注册表的可用性 (Availability) 要求很高，一般采用能满足高可用分布式一致的组件（例如 Zookeeper, Consul, Etcd 等）来实现。 Fig 2, 进程内 LB 方案 进程内 LB 方案是一种分布式方案，LB 和服务发现能力被分散到每一个服务消费者的进程内部，同时服务消费方和服务提供方之间是直接调用，没有额外开销，性能比较好。但是，该方案以客户库 (Client Library) 的方式集成到服务调用方进程里头，如果企业内有多种不同的语言栈，就要配合开发多种不同的客户端，有一定的研发和维护成本。另外，一旦客户端跟随服务调用方发布到生产环境中，后续如果要对客户库进行升级，势必要求服务调用方修改代码并重新发布，所以该方案的升级推广有不小的阻力。 进程内 LB 的案例是 Netflix 的开源服务框架，对应的组件分别是：Eureka 服务注册表，Karyon 服务端框架支持服务自注册和健康检查，Ribbon 客户端框架支持服务自发现和软路由。另外，阿里开源的服务框架 Dubbo 也是采用类似机制。 第三种是主机独立 LB 进程方案，该方案是针对第二种方案的不足而提出的一种折中方案，原理和第二种方案基本类似，不同之处是，他将 LB 和服务发现功能从进程内移出来，变成主机上的一个独立进程，主机上的一个或者多个服务要访问目标服务时，他们都通过同一主机上的独立 LB 进程做服务发现和负载均衡，见下图 Fig 3。 Fig 3 主机独立 LB 进程方案 该方案也是一种分布式方案，没有单点问题，一个 LB 进程挂了只影响该主机上的服务调用方，服务调用方和 LB 之间是进程内调用，性能好，同时，该方案还简化了服务调用方，不需要为不同语言开发客户库，LB 的升级不需要服务调用方改代码。该方案的不足是部署较复杂，环节多，出错调试排查问题不方便。 该方案的典型案例是 Airbnb 的 SmartStack 服务发现框架，对应组件分别是：Zookeeper 作为服务注册表，Nerve 独立进程负责服务注册和健康检查，Synapse/HAproxy 独立进程负责服务发现和负载均衡。Google 最新推出的基于容器的 PaaS 平台 Kubernetes，其内部服务发现采用类似的机制。 服务前端路由微服务除了内部相互之间调用和通信之外，最终要以某种方式暴露出去，才能让外界系统（例如客户的浏览器、移动设备等等）访问到，这就涉及服务的前端路由，对应的组件是服务网关 (Service Gateway)，见图 Fig 4，网关是连接企业内部和外部系统的一道门，有如下关键作用： 服务反向路由，网关要负责将外部请求反向路由到内部具体的微服务，这样虽然企业内部是复杂的分布式微服务结构，但是外部系统从网关上看到的就像是一个统一的完整服务，网关屏蔽了后台服务的复杂性，同时也屏蔽了后台服务的升级和变化。安全认证和防爬虫，所有外部请求必须经过网关，网关可以集中对访问进行安全控制，比如用户认证和授权，同时还可以分析访问模式实现防爬虫功能，网关是连接企业内外系统的安全之门。限流和容错，在流量高峰期，网关可以限制流量，保护后台系统不被大流量冲垮，在内部系统出现故障时，网关可以集中做容错，保持外部良好的用户体验。监控，网关可以集中监控访问量，调用延迟，错误计数和访问模式，为后端的性能优化或者扩容提供数据支持。日志，网关可以收集所有的访问日志，进入后台系统做进一步分析。 Fig 4, 服务网关 除以上基本能力外，网关还可以实现线上引流，线上压测，线上调试 (Surgical debugging)，金丝雀测试 (Canary Testing)，数据中心双活 (Active-Active HA) 等高级功能。 网关通常工作在 7 层，有一定的计算逻辑，一般以集群方式部署，前置 LB 进行负载均衡。 开源的网关组件有 Netflix 的 Zuul，特点是动态可热部署的过滤器 (filter) 机制，其它如 HAproxy，Nginx 等都可以扩展作为网关使用。 在介绍过服务注册表和网关等组件之后，我们可以通过一个简化的微服务架构图 (Fig 5) 来更加直观地展示整个微服务体系内的服务注册发现和路由机制，该图假定采用进程内 LB 服务发现和负载均衡机制。在下图 Fig 5 的微服务架构中，服务简化为两层，后端通用服务（也称中间层服务 Middle Tier Service）和前端服务（也称边缘服务 Edge Service，前端服务的作用是对后端服务做必要的聚合和裁剪后暴露给外部不同的设备，如 PC，Pad 或者 Phone）。后端服务启动时会将地址信息注册到服务注册表，前端服务通过查询服务注册表就可以发现然后调用后端服务；前端服务启动时也会将地址信息注册到服务注册表，这样网关通过查询服务注册表就可以将请求路由到目标前端服务，这样整个微服务体系的服务自注册自发现和软路由就通过服务注册表和网关串联起来了。如果以面向对象设计模式的视角来看，网关类似 Proxy 代理或者 Façade 门面模式，而服务注册表和服务自注册自发现类似 IoC 依赖注入模式，微服务可以理解为基于网关代理和注册表 IoC 构建的分布式系统。 Fig 5, 简化的微服务架构图 服务容错当企业微服务化以后，服务之间会有错综复杂的依赖关系，例如，一个前端请求一般会依赖于多个后端服务，技术上称为 1 -> N 扇出 (见图 Fig 6)。在实际生产环境中，服务往往不是百分百可靠，服务可能会出错或者产生延迟，如果一个应用不能对其依赖的故障进行容错和隔离，那么该应用本身就处在被拖垮的风险中。在一个高流量的网站中，某个单一后端一旦发生延迟，可能在数秒内导致所有应用资源 (线程，队列等) 被耗尽，造成所谓的雪崩效应 (Cascading Failure，见图 Fig 7)，严重时可致整个网站瘫痪。 Fig 6, 服务依赖 Fig 7, 高峰期单个服务延迟致雪崩效应 经过多年的探索和实践，业界在分布式服务容错一块探索出了一套有效的容错模式和最佳实践，主要包括： Fig 8, 弹性电路保护状态图 电路熔断器模式 (Circuit Breaker Patten), 该模式的原理类似于家里的电路熔断器，如果家里的电路发生短路，熔断器能够主动熔断电路，以避免灾难性损失。在分布式系统中应用电路熔断器模式后，当目标服务慢或者大量超时，调用方能够主动熔断，以防止服务被进一步拖垮；如果情况又好转了，电路又能自动恢复，这就是所谓的弹性容错，系统有自恢复能力。下图 Fig 8 是一个典型的具备弹性恢复能力的电路保护器状态图，正常状态下，电路处于关闭状态 (Closed)，如果调用持续出错或者超时，电路被打开进入熔断状态 (Open)，后续一段时间内的所有调用都会被拒绝 (Fail Fast)，一段时间以后，保护器会尝试进入半熔断状态 (Half-Open)，允许少量请求进来尝试，如果调用仍然失败，则回到熔断状态，如果调用成功，则回到电路闭合状态。舱壁隔离模式 (Bulkhead Isolation Pattern)，顾名思义，该模式像舱壁一样对资源或失败单元进行隔离，如果一个船舱破了进水，只损失一个船舱，其它船舱可以不受影响 。线程隔离 (Thread Isolation) 就是舱壁隔离模式的一个例子，假定一个应用程序 A 调用了 Svc1/Svc2/Svc3 三个服务，且部署 A 的容器一共有 120 个工作线程，采用线程隔离机制，可以给对 Svc1/Svc2/Svc3 的调用各分配 40 个线程，当 Svc2 慢了，给 Svc2 分配的 40 个线程因慢而阻塞并最终耗尽，线程隔离可以保证给 Svc1/Svc3 分配的 80 个线程可以不受影响，如果没有这种隔离机制，当 Svc2 慢的时候，120 个工作线程会很快全部被对 Svc2 的调用吃光，整个应用程序会全部慢下来。限流 (Rate Limiting/Load Shedder)，服务总有容量限制，没有限流机制的服务很容易在突发流量 (秒杀，双十一) 时被冲垮。限流通常指对服务限定并发访问量，比如单位时间只允许 100 个并发调用，对超过这个限制的请求要拒绝并回退。回退 (fallback)，在熔断或者限流发生的时候，应用程序的后续处理逻辑是什么？回退是系统的弹性恢复能力，常见的处理策略有，直接抛出异常，也称快速失败 (Fail Fast)，也可以返回空值或缺省值，还可以返回备份数据，如果主服务熔断了，可以从备份服务获取数据。Netflix 将上述容错模式和最佳实践集成到一个称为 Hystrix 的开源组件中，凡是需要容错的依赖点 (服务，缓存，数据库访问等)，开发人员只需要将调用封装在 Hystrix Command 里头，则相关调用就自动置于 Hystrix 的弹性容错保护之下。Hystrix 组件已经在 Netflix 经过多年运维验证，是 Netflix 微服务平台稳定性和弹性的基石，正逐渐被社区接受为标准容错组件。 服务框架微服务化以后，为了让业务开发人员专注于业务逻辑实现，避免冗余和重复劳动，规范研发提升效率，必然要将一些公共关注点推到框架层面。服务框架 (Fig 9) 主要封装公共关注点逻辑，包括： Fig 9, 服务框架 服务注册、发现、负载均衡和健康检查，假定采用进程内 LB 方案，那么服务自注册一般统一做在服务器端框架中，健康检查逻辑由具体业务服务定制，框架层提供调用健康检查逻辑的机制，服务发现和负载均衡则集成在服务客户端框架中。监控日志，框架一方面要记录重要的框架层日志、metrics 和调用链数据，还要将日志、metrics 等接口暴露出来，让业务层能根据需要记录业务日志数据。在运行环境中，所有日志数据一般集中落地到企业后台日志系统，做进一步分析和处理。REST/RPC 和序列化，框架层要支持将业务逻辑以 HTTP/REST 或者 RPC 方式暴露出来，HTTP/REST 是当前主流 API 暴露方式，在性能要求高的场合则可采用 Binary/RPC 方式。针对当前多样化的设备类型 (浏览器、普通 PC、无线设备等)，框架层要支持可定制的序列化机制，例如，对浏览器，框架支持输出 Ajax 友好的 JSON 消息格式，而对无线设备上的 Native App，框架支持输出性能高的 Binary 消息格式。配置，除了支持普通配置文件方式的配置，框架层还可集成动态运行时配置，能够在运行时针对不同环境动态调整服务的参数和配置。限流和容错，框架集成限流容错组件，能够在运行时自动限流和容错，保护服务，如果进一步和动态配置相结合，还可以实现动态限流和熔断。管理接口，框架集成管理接口，一方面可以在线查看框架和服务内部状态，同时还可以动态调整内部状态，对调试、监控和管理能提供快速反馈。Spring Boot 微框架的 Actuator 模块就是一个强大的管理接口。统一错误处理，对于框架层和服务的内部异常，如果框架层能够统一处理并记录日志，对服务监控和快速问题定位有很大帮助。安全，安全和访问控制逻辑可以在框架层统一进行封装，可做成插件形式，具体业务服务根据需要加载相关安全插件。文档自动生成，文档的书写和同步一直是一个痛点，框架层如果能支持文档的自动生成和同步，会给使用 API 的开发和测试人员带来极大便利。Swagger 是一种流行 Restful API 的文档方案。当前业界比较成熟的微服务框架有 Netflix 的 Karyon/Ribbon，Spring 的 Spring Boot/Cloud，阿里的 Dubbo 等。 运行期配置管理服务一般有很多依赖配置，例如访问数据库有连接字符串配置，连接池大小和连接超时配置，这些配置在不同环境 (开发 / 测试 / 生产) 一般不同，比如生产环境需要配连接池，而开发测试环境可能不配，另外有些参数配置在运行期可能还要动态调整，例如，运行时根据流量状况动态调整限流和熔断阀值。目前比较常见的做法是搭建一个运行时配置中心支持微服务的动态配置，简化架构如下图 (Fig 10): Fig 10, 服务配置中心 动态配置存放在集中的配置服务器上，用户通过管理界面配置和调整服务配置，具体服务通过定期拉 (Scheduled Pull) 的方式或者服务器推 (Server-side Push) 的方式更新动态配置，拉方式比较可靠，但会有延迟同时有无效网络开销 (假设配置不常更新)，服务器推方式能及时更新配置，但是实现较复杂，一般在服务和配置服务器之间要建立长连接。配置中心还要解决配置的版本控制和审计问题，对于大规模服务化环境，配置中心还要考虑分布式和高可用问题。 配置中心比较成熟的开源方案有百度的 Disconf，360 的 QConf，Spring 的 Cloud Config 和阿里的 Diamond 等。 Netflix 的微服务框架Netflix 是一家成功实践微服务架构的互联网公司，几年前，Netflix 就把它的几乎整个微服务框架栈开源贡献给了社区，这些框架和组件包括： Eureka:　服务注册发现框架Zuul:　服务网关Karyon:　服务端框架Ribbon:　客户端框架Hystrix: 服务容错组件Archaius: 服务配置组件Servo: Metrics 组件Blitz4j: 日志组件下图 Fig 11 展示了基于这些组件构建的一个微服务框架体系，来自 recipes-rss。 Fig 11, 基于 Netflix 开源组件的微服务框架 Netflix 的开源框架组件已经在 Netflix 的大规模分布式微服务环境中经过多年的生产实战验证，正逐步被社区接受为构造微服务框架的标准组件。Pivotal 去年推出的 Spring Cloud 开源产品，主要是基于对 Netflix 开源组件的进一步封装，方便 Spring 开发人员构建微服务基础框架。对于一些打算构建微服务框架体系的公司来说，充分利用或参考借鉴 Netflix 的开源微服务组件 (或 Spring Cloud)，在此基础上进行必要的企业定制，无疑是通向微服务架构的捷径。 原文地址：https://www.infoq.cn/article/basis-frameworkto-implement-micro-service#anch130564%20%EF%BC%8C

深入浅出Spring Boot 2.x Spring Boot实战JavaEE开发的颠覆者：Spring Boot实战Spring Boot 2精髓：从构建小系统到架构

Java之JVM垃圾回收 内存结构以及垃圾回收算法前言：由于小组技术分享的需要，懂的不是很多所以我就找了这个我自己感兴趣的知识点给大家做个简单的介绍。由于是新人，算不了很懂，只是总结性的讲了些概念性的东西。给大家分享的同时，算是给自己做个笔记吧。作为Java语言的核心之一，JVM垃圾回收帮我们解决了让我们很头疼的垃圾回收问题。我们不需要像VC++一样，作为内存管理的统治者需要我们对我们分配的每一块内存进行回收，否则就会造成内存泄露问题。是不是只要有JVM存在我们就不会出现内存泄露问题，出现内存泄露问题我们又该怎么办，如果我们想提高我们程序的稳定性和其他性能我们能从什么地方下手！！！相信这些问题是我们程序过程中不可逾越的。了解JVM的内存分配及其相应的垃圾回收机制，不仅仅是可以了解底层的JVM运行机制，而且对于程序性能的优化和提升还是很有必要的。一、JVM内存分配区域结构图一从图一可以看出JVM中的内存分配包括PC Register(PC寄存器) JVM栈 堆（Heap） 方法区域（MethodArea）运行时常量池（RuntimeConstant Pool） 本地方法堆栈（NativeMethod Stacks），这几部分区域但是从程序员的角度来看我们只关注JVM Heap和JVM Stack，因为这两部分是直接关系程序运行期间的内存状态，所以我会主要介绍这两部分内存，其他的我只是给出了简单的一些概念性解释：PC Register(Program Counter 寄存器):主要作用是记录当前线程所执行的字节码的行号。方法区域（MethodArea）:方法区域存放了所加载的类的信息（名称、修饰符等）、类中的静态变量、类中定义为final类型的常量、类中的Field信息、类中的方法信息，法区域也是全局共享的，它在虚拟机启动时在一定的条件下它也会被GC，当方法区域需要使用的内存超过其允许的大小时，会抛出OutOfMemory的错误信息。运行时常量池（RuntimeConstant Pool):存放的为类中的固定的常量信息、方法和Field的引用信息等，其空间从方法区域中分配。本地方法堆栈（NativeMethod Stacks）:JVM采用本地方法堆栈来支持native方法的执行，此区域用于存储每个native方法调用的状态。JVM栈：主要存放一些基本类型的变量和对象的引用变量。JVM堆：用来存放由 new 创建的对象和数组Java 虚拟机的自动垃圾回收器来管理（注意数组也是对象，所以说数组也是存放在JVM堆中）。由于栈中存放的是主要存放一些基本类型的变量和对象的引用变量，所以当过了变量的作用区域或者是当程序运行结束后它所占用的内存会自动的释放掉，所以不用来关心，下面我们主要来说的是堆内存的分配以及回收的算法。二、JVM堆内存介绍工欲善其事，必先利其器。所以了解堆内存的内部结构是很必要的。在Jvm中堆空间划分为三个代：年轻代（Young Generation）、年老代（Old Generation）和永久代（Permanent Generation）。年轻带主要是动态的存储，年轻带主要储存新产生的对象，年老代储存年龄大些的对象，永久带主要是存储的是java的类信息，包括解析得到的方法、属性、字段等。永久带基本不参与垃圾回收。所以说我们说的垃圾回收主要是针对年轻代和年老代。图二年轻代又分成3个部分，一个eden区和两个相同的survior区。刚开始创建的对象都是放置在eden区的。分成这样3个部分，主要是为了生命周期短的对象尽量留在年轻带。当eden区申请不到空间的时候，进行minorGC，把存活的对象拷贝到survior。年老代主要存放生命周期比较长的对象，比如缓存对象。（经过IBM的一个研究机构研究数据表明，基本上80%-98%的对象都会在年轻代的Eden区死掉从而本回收掉，所以说真正进入到老年代的对象很少，这也是为什么MinorGC比MajorGC更加频繁的原因）具体JVM内存垃圾回收过程描述如下 ：1、对象在Eden区完成内存分配2、当Eden区满了，再创建对象，会因为申请不到空间，触发minorGC，进行young(eden+1survivor)区的垃圾回收3、minorGC时，Eden不能被回收的对象被放入到空的survivor（Eden肯定会被清空），另一个survivor里不能被GC回收的对象也会被放入这个survivor，始终保证一个survivor是空的4、当做第3步的时候，如果发现survivor满了，则这些对象被copy到old区，或者survivor并没有满，但是有些对象已经足够Old，也被放入Old区 XX:MaxTenuringThreshold5、当Old区被放满的之后，进行fullGC补充： MinorGC：年轻代所进行的垃圾回收，非常频繁，一般回收速度也比较快。 MajorGC：老年代进行的垃圾回收，发生一次MajorGC至少伴随一次MinorGC，一般比MinorGC速度慢十倍以上。 FullGC：整个堆内存进行的垃圾回收，很多时候是MajorGC 以后就是堆内存结构已经大致的垃圾回收过程。三、对象分配原则1.对象优先分配在Eden区，如果Eden区没有足够的空间时，虚拟机执行一次Minor GC。2.大对象直接进入老年代（大对象是指需要大量连续内存空间的对象）。这样做的目的是避免在Eden区和两个Survivor区之间发生大量的内存拷贝（新生代采用复制算法收集内存）。3.长期存活的对象进入老年代。虚拟机为每个对象定义了一个年龄计数器，如果对象经过了1次Minor GC那么对象会进入Survivor区，之后每经过一次Minor GC那么对象的年龄加1，知道达到阀值对象进入老年区。4.动态判断对象的年龄。如果Survivor区中相同年龄的所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象可以直接进入老年代。5.空间分配担保。每次进行Minor GC时，JVM会计算Survivor区移至老年区的对象的平均大小，如果这个值大于老年区的剩余值大小则进行一次Full GC，如果小于检查HandlePromotionFailure设置，如果true则只进行Monitor GC,如果false则进行Full GC。四、垃圾收集器作为JVM中的核心之一垃圾收集器，主要完成的功能包括：（1）发现无用信息对象；（2）回收被无用对象占用的内存空间，使该空间可被程序再次使用。所以说我们在实现垃圾收集器的同时就要实现两个算法一个是发现无用的对象第二就是回收该对象的内存。收集器主要分为引用计数器和跟踪收集器两种，Sun JDK中采用跟踪收集器作为GC实现策略。发现无用对象只要的实现算法包括引用计数法和根搜索算法，引用计数法主要是JVM的早期实现方法，因为引用计数无法解决循环引用的问题，所以现在JVM实现的主要是根搜索算法，引用计数法：堆中的每个对象对应一个引用计数器。当每一次创建一个对象并赋给一个变量时，引用计数器置为1。当对象被赋给任意变量时，引用计数器每次加1当对象出了作用域后(该对象丢弃不再使用)，引用计数器减1，一旦引用计数器为0，对象就不可用从而可以被回收。 根搜索算法：通过一系列的名为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到GC Roots没有任何引用链相连（用图论的话来说就是从GC Roots到这个对象不可达）时，则证明此对象是不可用的。目前的收集器主要有三种：串行收集器：使用单线程处理所有垃圾回收工作，因为无需多线程交互，所以效率比较高并行收集器：对年轻代进行并行垃圾回收，因此可以减少垃圾回收时间。一般在多线程多处理器机器上使用并发收集器：可以保证大部分工作都并发进行（应用不停止），垃圾回收只暂停很少的时间，此收集器适合对响应时间要求比较高的中、大规模应用五、垃圾收集器的回收算法Copying算法：算法：复制采用的方式为从根集合扫描出存活的对象，并将找到的存活对象复制到一块新的完全未使用的空间中。 过程： 此算法把内存空间划为两个相等的区域，每次只使用其中一个区域。垃圾回收时，遍历当前使用区域，把正在使用中的对象复制到另外一个区域中。次算法每次只处理正在使用中的对象，因此复制成本比较小，同时复制过去以后还能进行相应的内存整理，不过出现“碎片”问题。当然，此算法的缺点也是很明显的，就是需要两倍内存空间。Mark-Sweep算法： 算法：标记-清除采用的方式为从根集合开始扫描，对存活的对象进行标记，标记完毕后，再扫描整个空间中未标记的对象，并进行回收。 过程： 第一阶段从引用根节点开始标记所有被引用的对象，第二阶段遍历整个堆，把未标记的对象清除。它停止所有工作，收集器从根开始访问每一个活跃的节点，标记它所访问的每一个节点。走过所有引用后，收集就完成了，然后就对堆进行清除（即对堆中的每一个对象进行检查），所有没有标记的对象都作为垃圾回收并返回空闲列表。Mark-Compact算法： 算法：标记阶段与“Mark-Sweep”算法相同，但在清除阶段有所不同。在回收不存活对象所占用的内存空间后，会将其他所有存活对象都往左端空闲的空间进行移动，并更新引用其对象指针。过程：此算法结合了“标记-清除”和“复制”两个算法的优点。也是分两阶段，第一阶段从根节点开始标记所有被引用对象，第二阶段遍历整个堆，把清除未标记对象并且把存活对象“压缩”到堆的其中一块，按顺序排放。此算法避免了“标记-清除”的碎片问题，同时也避免了“复制”算法的空间问题。Sun JDK GC策略：新生代算法实现：Copying,Copying,Copying旧生代算发实现：Mark-Sweep-Compact，Mark –Compact，Mark –Sweep！！六、JvisuaVM 工具如果我们想优化自己的程序，那么我们就必须清楚的了解不同代码程序所消耗的性能多少，作为JDK的一部分，这个工具给我们提供了很大的帮助。这个工具可以在JDK的bin目录下找到，功能很强大，可以注意利用

可以使用MAT进行内存分析MAT使用教程http://blog.csdn.net/itomge/article/details/48719527MAT - Memory Analyzer Tool 使用进阶http://www.lightskystreet.com/2015/09/01/mat_usage/

可以使用MAT进行内存分析MAT使用教程http://blog.csdn.net/itomge/article/details/48719527MAT - Memory Analyzer Tool 使用进阶http://www.lightskystreet.com/2015/09/01/mat_usage/

可能是同事懒不写，也可能是理念不一样，他认为接口已经能说明一切了。可以看下《重构》这本书，这本书里面有个很有意思的观念，好的接口名字已经能起到注释的功能，注释写的长说明需要重构了。

android 开发基本都用gradle了

关于线程和线程池的学习，我们可以从以下几个方面入手： 第一，什么是线程，线程和进程的区别是什么 第二，线程中的基本概念，线程的生命周期 第三，单线程和多线程 第四，线程池的原理解析 第五，常见的几种线程池的特点以及各自的应用场景 一、 线程，程序执行流的最小执行单位，是行程中的实际运作单位，经常容易和进程这个概念混淆。那么，线程和进程究竟有什么区别呢？首先，进程是一个动态的过程，是一个活动的实体。简单来说，一个应用程序的运行就可以被看做是一个进程，而线程，是运行中的实际的任务执行者。可以说，进程中包含了多个可以同时运行的线程。 二、 线程的生命周期，线程的生命周期可以利用以下的图解来更好的理解： 第一步，是用new Thread()的方法新建一个线程，在线程创建完成之后，线程就进入了就绪（Runnable）状态，此时创建出来的线程进入抢占CPU资源的状态，当线程抢到了CPU的执行权之后，线程就进入了运行状态（Running），当该线程的任务执行完成之后或者是非常态的调用的stop（）方法之后，线程就进入了死亡状态。而我们在图解中可以看出，线程还具有一个则色的过程，这是怎么回事呢？当面对以下几种情况的时候，容易造成线程阻塞，第一种，当线程主动调用了sleep（）方法时，线程会进入则阻塞状态，除此之外，当线程中主动调用了阻塞时的IO方法时，这个方法有一个返回参数，当参数返回之前，线程也会进入阻塞状态，还有一种情况，当线程进入正在等待某个通知时，会进入阻塞状态。那么，为什么会有阻塞状态出现呢？我们都知道,CPU的资源是十分宝贵的，所以，当线程正在进行某种不确定时长的任务时，Java就会收回CPU的执行权，从而合理应用CPU的资源。我们根据图可以看出，线程在阻塞过程结束之后，会重新进入就绪状态，重新抢夺CPU资源。这时候，我们可能会产生一个疑问，如何跳出阻塞过程呢?又以上几种可能造成线程阻塞的情况来看，都是存在一个时间限制的，当sleep()方法的睡眠时长过去后，线程就自动跳出了阻塞状态，第二种则是在返回了一个参数之后，在获取到了等待的通知时，就自动跳出了线程的阻塞过程 三、 什么是单线程和多线程？ 单线程，顾名思义即是只有一条线程在执行任务，这种情况在我们日常的工作学习中很少遇到，所以我们只是简单做一下了解 多线程，创建多条线程同时执行任务，这种方式在我们的日常生活中比较常见。但是，在多线程的使用过程中，还有许多需要我们了解的概念。比如，在理解上并行和并发的区别，以及在实际应用的过程中多线程的安全问题，对此，我们需要进行详细的了解。 并行和并发：在我们看来，都是可以同时执行多种任务，那么，到底他们二者有什么区别呢？ 并发，从宏观方面来说，并发就是同时进行多种时间，实际上，这几种时间，并不是同时进行的，而是交替进行的，而由于CPU的运算速度非常的快，会造成我们的一种错觉，就是在同一时间内进行了多种事情 而并发，则是真正意义上的同时进行多种事情。这种只可以在多核CPU的基础下完成。 还有就是多线程的安全问题？为什么会造成多线程的安全问题呢？我们可以想象一下，如果多个线程同时执行一个任务，name意味着他们共享同一种资源，由于线程CPU的资源不一定可以被谁抢占到，这是，第一条线程先抢占到CPU资源，他刚刚进行了第一次操作，而此时第二条线程抢占到了CPU的资源，name，共享资源还来不及发生变化，就同时有两条数据使用了同一条资源，具体请参考多线程买票问题。这个问题我们应该如何解决那？   有造成问题的原因我们可以看出，这个问题主要的矛盾在于，CPU的使用权抢占和资源的共享发生了冲突，解决时，我们只需要让一条线程战歌了CPU的资源时，阻止第二条线程同时抢占CPU的执行权，在代码中，我们只需要在方法中使用同步代码块即可。在这里，同步代码块不多进行赘述，可以自行了解。 四，线程池 又以上介绍我们可以看出，在一个应用程序中，我们需要多次使用线程，也就意味着，我们需要多次创建并销毁线程。而创建并销毁线程的过程势必会消耗内存。而在Java中，内存资源是及其宝贵的，所以，我们就提出了线程池的概念。 线程池：Java中开辟出了一种管理线程的概念，这个概念叫做线程池，从概念以及应用场景中，我们可以看出，线程池的好处，就是可以方便的管理线程，也可以减少内存的消耗。 那么，我们应该如何创建一个线程池那?Java中已经提供了创建线程池的一个类：Executor 而我们创建时，一般使用它的子类：ThreadPoolExecutor. public ThreadPoolExecutor(int corePoolSize,                                int maximumPoolSize,                                long keepAliveTime,                                TimeUnit unit,                                BlockingQueue workQueue,                                ThreadFactory threadFactory,                                RejectedExecutionHandler handler)这是其中最重要的一个构造方法，这个方法决定了创建出来的线程池的各种属性，下面依靠一张图来更好的理解线程池和这几个参数： 又图中，我们可以看出，线程池中的corePoolSize就是线程池中的核心线程数量，这几个核心线程，只是在没有用的时候，也不会被回收，maximumPoolSize就是线程池中可以容纳的最大线程的数量，而keepAliveTime，就是线程池中除了核心线程之外的其他的最长可以保留的时间，因为在线程池中，除了核心线程即使在无任务的情况下也不能被清除，其余的都是有存活时间的，意思就是非核心线程可以保留的最长的空闲时间，而util，就是计算这个时间的一个单位，workQueue，就是等待队列，任务可以储存在任务队列中等待被执行，执行的是FIFIO原则（先进先出）。threadFactory，就是创建线程的线程工厂，最后一个handler,是一种拒绝策略，我们可以在任务满了知乎，拒绝执行某些任务。 线程池的执行流程又是怎样的呢？ 有图我们可以看出，任务进来时，首先执行判断，判断核心线程是否处于空闲状态，如果不是，核心线程就先就执行任务，如果核心线程已满，则判断任务队列是否有地方存放该任务，若果有，就将任务保存在任务队列中，等待执行，如果满了，在判断最大可容纳的线程数，如果没有超出这个数量，就开创非核心线程执行任务，如果超出了，就调用handler实现拒绝策略。 handler的拒绝策略： 有四种：第一种AbortPolicy:不执行新任务，直接抛出异常，提示线程池已满              第二种DisCardPolicy:不执行新任务，也不抛出异常              第三种DisCardOldSetPolicy:将消息队列中的第一个任务替换为当前新进来的任务执行              第四种CallerRunsPolicy:直接调用execute来执行当前任务 五，四种常见的线程池： CachedThreadPool:可缓存的线程池，该线程池中没有核心线程，非核心线程的数量为Integer.max_value，就是无限大，当有需要时创建线程来执行任务，没有需要时回收线程，适用于耗时少，任务量大的情况。 SecudleThreadPool:周期性执行任务的线程池，按照某种特定的计划执行线程中的任务，有核心线程，但也有非核心线程，非核心线程的大小也为无限大。适用于执行周期性的任务。 SingleThreadPool:只有一条线程来执行任务，适用于有顺序的任务的应用场景。 FixedThreadPool:定长的线程池，有核心线程，核心线程的即为最大的线程数量，没有非核心线程 作者：weixin_40271838 来源：CSDN 原文：https://blog.csdn.net/weixin_40271838/article/details/79998327 版权声明：本文为博主原创文章，转载请附上博文链接！

你可以用chrome的调试功能看下别人的接口是怎么设计的，比如我用现在的问答界面开启调试看了下调用：https://yq.aliyun.com/yqnew/api/csp/report返回{'errcode':0,'errmsg':'','success':true,'data':{}}类似的，你可以找找其他别的页面接口是怎么设计的参考下

spring boot很多开箱即用的特性，导致默认的配置很难找，你可以看下annotation对应的实现，应该是有设置的

203、202 应该是返回的错误码，可以查看下接入说明应该有详细的描述。图片为存秘钥的文件，对命名有要求，你可以重命名成yw_0335.jpg试下，能不能跑通。

可以使用iframe形式集成到你自己的网页中