类的加载过程_对象的创建过程_dubbo原理和通信协议_dubbo和spring对比_rpc和http调用的区别_http1

类的加载过程_对象的创建过程_dubbo原理和通信协议_dubbo和spring对比_rpc和http调用的区别_http1

对象创建的过程（简单理解）

详细的过程

java创建对象的过程主要分为一下五个步骤：（1）类加载检查Java虚拟机（jvm）在读取一条new指令时候，首先检查能否在常量池中定位到这个类的符号引用，并且检查这个符号引用代表的类是否被加载、解析和初始化。如果没有，则会先执行相应的类加载过程。

（2）内存分配在通过（1）后，则开始为新生的对象分配内存。该对象所需的内存大小在类加载完成后便可确定，因此为每个对象分配的内存大小是确定的。而分配方式主要有两种，分别为：

1.指针碰撞

应用场合：堆内存规整（通俗的说就是用过的内存被整齐充分的利用，用过的内存放在一边，没有用过的放在另外一边，而中间利用一个分界值指针对这两边的内存进行分界，从而掌握内存分配情况）。

即在开辟内存空间时候，将分界值指针往没用过的内存方向移动向应大小位置即可）。

将堆内存这样划分的代表的GC收集器算法有：Serial，ParNew

2.空闲列表

应用场合;堆内存不规整（虚拟机维护一个可以记录内存块是否可以用的列表来了解内存分配情况）

即在开辟内存空间时候，找到一块足够大的内存块分配给该对象即可，同时更新记录列表。

将堆内存这样划分的代表的GC收集器算法有：CMS

（3）初始化默认值第（2）步完成后，紧接着，虚拟机需要将分配到的内存空间都进行初始化（即给一些默认值），这将做是为了保证对象实例的字段在Java代码中可以在不赋初值的情况下使用。程序可以访问到这些字段对用数据类型的默认值。

（4）设置对象头初始化（3）完成后，虚拟机对对象进行一些简单设置，如标记该对象是哪个类的实例，这个对象的hash码，该对象所处的年龄段等等（这些可以理解为对象实例的基本信息）。这些信息被写在对象头中。jvm根据当前的运行状态，会给出不同的设置方式。

（5）执行初始化方法在（4）完成后，最后执行由开发人员编写的对象的初始化方法，把对象按照开发人员的设计进行初始化，一个对象便创建出来了。

dubbo原理

主要包括五个节点：Provider、Consumer、Container、Register、Monitor

Provider：服务提供者Consumer：服务订阅者Container：服务运行的容器Register：注册中心Monitor：监控中心，统计服务调用次数和调动时间

dubbo工作过程：

服务容器负责启动，加载，运行服务提供者。服务提供者在启动时，向注册中心注册自己提供的服务。服务消费者在启动时，向注册中心订阅自己所需的服务。注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心

三、dubbo支持哪些的通信协议

协议：

基于 表单的远程调用协议，短连接，json 序列化对传输数据包不限，不支持传文件适用于同时给应用程序和浏览器 JS 使用的服务

dubbo 默认协议：

单一 TCP 长连接，Hessian 二进制序列化和 NIO 异步通讯适合于小数据包大并发的服务调用和服务消费者数远大于服务提供者数的情况不适合传送大数据包的服务

rmi 协议：

采用 JDK 标准的 java.rmi.* 实现，采用阻塞式短连接和 JDK 标准序列化方式如果服务接口继承了 java.rmi.Remote 接口，可以和原生 RMI 互操作对传输数据包不限，消费者和传输者个数相当

rpc和和 HTTP1.1 的区别?

长连接：HTTP1.0 默认使用短连接，每次请求都需要建立新的 TCP 连接，连接不能复用。HTTP1.1 支持长连接，复用 TCP 连接，允许客户端通过同一连接发送多个请求。不过，这个优化策略也存在问题，当一个队头的请求不能收到响应的资源时，它将会阻塞后面的请求。这就是“队头阻塞”问题。断点续传：HTTP1.0 不支持断点续传。HTTP1.1 新增了 range 字段，用来指定数据字节位置，支持断点续传。错误状态响应码：在 HTTP1.1 中新增了 24 个错误状态响应码，如​​409（Conflict）​​表示请求的资源与资源的当前状态发生冲突、​​410（Gone）​​表示服务器上的某个资源被永久性的地删除。Host 头处理：在 HTTP1.0 中认为每台服务器都绑定一个唯一的 IP 地址，因此，请求消息中的 URL 并没有传递主机名。到了 HTTP1.1 时代，虚拟主机技术发展迅速，在一台物理服务器上可以存在多个虚拟主机，并且它们共享一个 IP 地址，故 HTTP1.1 增加了 HOST 信息

HTTP1.1 和 HTTP2.0 的区别？

HTTP2.0 相比 HTTP1.1 支持的特性：

新的二进制格式：HTTP1.1 基于文本格式传输数据；HTTP2.0 采用二进制格式传输数据，解析更高效。多路复用：在一个连接里，允许同时发送多个请求或响应，并且这些请求或响应能够并行地传输而不被阻塞，避免 HTTP1.1 出现的“队头堵塞”问题。头部压缩，HTTP1.1 的 header 带有大量信息，而且每次都要重复发送；HTTP2.0 把 header 从数据中分离，并封装成头帧和数据帧，使用特定算法压缩头帧，有效减少头信息大小。并且 HTTP2.0 在客户端和服务器端记录了之前发送的键值对，对于相同的数据，不会重复发送。比如请求 a 发送了所有的头信息字段，请求 b 则只需要发送差异数据，这样可以减少冗余数据，降低开销。服务端推送：HTTP2.0 允许服务器向客户端推送资源，无需客户端发送请求到服务器获取。

hello信息，告诉服务端需要的tls版本信息，支持的加密算法有哪些，这些算法组成加密套件，然后是一个随机数。

然后第二次握手服务端向客户端发送一个Server hello，然后告诉客户端服务端支持的确认支持的tls版本以及选择的加密套件，也会生成一个随机数告诉客户端，然后服务器出示一个证书，这样浏览器可以根据自己信任的证书列表来确认这个证书服务器是否可信，

然后把公钥给客户端，再发后一个结束信号，Server Hello Done

第三次握手会使用公钥加密生成预主密钥给服务端，服务端使用私钥解密，接下来使用预祝密钥和前两个随机数组成最终的密钥进行密钥通信，

第四次握手服务端发送一个信号对客户端进行确认，加密通信开始。

CA机构在其中的作用

ca机构是第三方机构用来保证数据的可靠性，ca机构给服务端提供公钥和私钥，然后把公钥安全的传输给客户端，方便后面的对称加密，那么如何保证公钥安全的给客户端呢，因为可以保证不能被篡改和更换

如何证明浏览器收到的公钥一定是该网站的公钥？

其实所有证明的源头都是一条或多条不证自明的“公理”（可以回想一下数学上公理），由它推导出一切。比如现实生活中，若想证明某身份证号一定是小明的，可以看他身份证，而身份证是由政府作证的，这里的“公理”就是“政府机构可信”，这也是社会正常运作的前提。

那能不能类似地有个机构充当互联网世界的“公理”呢？让它作为一切证明的源头，给网站颁发一个“身份证”？

它就是CA机构，它是如今互联网世界正常运作的前提，而CA机构颁发的“身份证”就是数字证书。

数字证书

网站在使用HTTPS前，需要向CA机构申领一份数字证书，数字证书里含有证书持有者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书里获取公钥就行了，证书就如身份证，证明“该公钥对应该网站”。而这里又有一个显而易见的问题，“证书本身的传输过程中，如何防止被篡改”？即如何证明证书本身的真实性？身份证运用了一些防伪技术，而数字证书怎么防伪呢？解决这个问题我们就接近胜利了！

如何放防止数字证书被篡改？

我们把证书原本的内容生成一份“签名”，比对证书内容和签名是否一致就能判别是否被篡改。这就是数字证书的“防伪技术”，这里的“签名”就叫​​数字签名​​：

数字签名

这部分内容建议看下图并结合后面的文字理解，图中左侧是数字签名的制作过程，右侧是验证过程：

数字签名的生成与验证（= 未完成三次握手队列 +  已经完成三次握手队列。

未完成三次握手队列：服务器处于listen状态时，收到客户端syn报文（connect）时放入未完成队列中。

已完成三次握手队列：三次握手的第二个状态即服务器syn+ack响应client后，此时第三个状态ack报文到达前（客户端对服务器syn的ack）一直保留在未完成连接队列中。若三次握手完成，该条目将从未完成连接队列搬到已完成连接队列尾部。当server调用accept时，从已完成三次握手队列中的头部取出一个socket连接给进程

backlog参数设置既可在linux内核参数设置(修改文件/etc/sysctl相关参数)，也可在socket系统调用listen函数时设置(第二个参数)。这二者区别是前者为全局性的，影响所有socket，后者为局部性的，影响当前socket。

若backlog设置过小可能会出现以下情况：server的accpet速度跟不上，导致A、B队列满了，导致新的客户端无法连接。

作者：你的雷哥

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。