精华内容
参与话题
问答
  • 触发的事件函数 public static void Publisher() { Phone phone = new Phone() { Id = 123, Name = "华为P9", Price = 2499 }; // 执行订阅 Subscriber();

    触发的事件函数

    public static void Publisher()
            {
                Phone phone = new Phone()
                {
                    Id = 123,
                    Name = "华为P9",
                    Price = 2499
                };
                // 执行订阅
                Subscriber()//价格变动会触发订阅者里的函数
                phone.Price = 500;
            }
    
    

    发布者

    /// <summary>
            /// 事件的发布者,发布事件并且在满足条件的情况下,触发事件
            /// </summary>
            public class Phone
            {
                public int Id { get; set; }
    
                public string Name { get; set; }
    
    
                private int _price;
    
                public int Price
                {
                    get
                    {
                        return _price;
                    }
                    set
                    {
                        if (value < _price) //降价了
                        {
                            this.DiscountHandler?.Invoke(this, new XEventArgs()
                            {
                                OldPrice = _price,
                                NewPrice = value
                            });
                        }
    
                        this._price = value;
    
                    }
                }
    
                public event EventHandler DiscountHandler;
            }
    
    

    订阅者

    public static void Subscriber()
            {
                //订阅:就是把订户和事件发布者关联起来
                phone.DiscountHandler += new Teacher().Buy;
                phone.DiscountHandler += new Student().Buy;
            }
    
    

    订阅者类

    /// <summary>
    /// 订户 关注事件,事件发生之后,自己做出相应的动作
    /// 价格变动会触发BUY函数
    /// </summary>
            public class Teacher
            {
                public void Buy(object sender, EventArgs e)
                {
                    Phone phone = (Phone)sender;
                    Console.WriteLine($"this is {phone.Name}");
                    XEventArgs xEventArgs = (XEventArgs)e;
                    Console.WriteLine($"之前的价格{xEventArgs.OldPrice}");
                    Console.WriteLine($"现在的价格{xEventArgs.NewPrice}");
                    Console.WriteLine("买下来");
    
                }
            }
    
            public class Student
            {
                public void Buy(object sender, EventArgs e)
                {
                    Phone phone = (Phone)sender;
                    Console.WriteLine($"this is {phone.Name}");
                    XEventArgs xEventArgs = (XEventArgs)e;
                    Console.WriteLine($"之前的价格{xEventArgs.OldPrice}");
                    Console.WriteLine($"现在的价格{xEventArgs.NewPrice}");
                    Console.WriteLine("买下来");
    
                }
            }
    
    

    事件参数

    public class XEventArgs : EventArgs
            {
                public int OldPrice { get; set; }
    
                public int NewPrice { get; set; }
    
            }
    
    
    展开全文
  • Docker是一个C/S架构(client/server) docker的守护进程运行在主机上,通过socket连接从客户端访问, 守护进程从客户端接受命令并管理运行在主机上的容器。 Docker的特点 ...docker有着比虚拟机更少的抽象层。...

    Docker是一个C/S架构(client/server)

    docker的守护进程运行在主机上,通过socket连接从客户端访问,

    守护进程从客户端接受命令并管理运行在主机上的容器。

     

    Docker的特点

    1. docker有着比虚拟机更少的抽象层。不需要Hypervisor实现硬件资源虚拟化,运行在docker的容器直接使用物理机的硬件资源
    2. docker利用的是宿主机的内核,不需要重新加载一个系统内核。

     

    docker结构和层次关系

    虚拟机和docker的区别

    首先观看一下虚拟机的架构

      Docker容器 虚拟机
    操作系统 与主机共享 在宿主机上运行一个虚拟的操作系统
    存储大小 镜像小,便于传输和存储 镜像庞大
    移植性 轻便、灵活,适用于linux 笨重,与虚拟化技术高耦合
    硬件亲和性 面相软件开发者 面向硬件运维者
    运行性能 几乎无性能损耗 额外消耗cpu和内存
    部署速度 快速、秒级 较慢,10秒以上

     

    展开全文
  • dubbo的底层原理

    万次阅读 多人点赞 2017-12-03 14:01:37
    一、Duboo基本概念解释 Dubbo是一种分布式服务框架。 Webservice也是一种服务框架,但是webservice并不是分布式的服务框架,他需要结合F5实现负载均衡。因此,dubbo除了可以提供服务之外,还可以实现软负载均衡。...

    一、Duboo基本概念解释

    Dubbo是一种分布式服务框架。 Webservice也是一种服务框架,但是webservice并不是分布式的服务框架,他需要结合F5实现负载均衡。因此,dubbo除了可以提供服务之外,还可以实现软负载均衡。它还提供了两个功能Monitor 监控中心和调用中心。这两个是可选的,需要单独配置。

    Dubbo的计数架构图如下:

    这里写图片描述

    我们解释以下这个架构图:

    Consumer服务消费者,Provider服务提供者。Container服务容器。消费当然是invoke提供者了,invoke这条实线按照图上的说明当然同步的意思了,多说一句,在实际调用过程中,Provider的位置对于Consumer来说是透明的,上一次调用服务的位置(IP地址)和下一次调用服务的位置,是不确定的。这个地方就是实现了软负载。

    服务提供者先启动start,然后注册register服务。

    消费订阅subscribe服务,如果没有订阅到自己想获得的服务,它会不断的尝试订阅。新的服务注册到注册中心以后,注册中心会将这些服务通过notify到消费者。

    Monitor这是一个监控,图中虚线表明Consumer 和Provider通过异步的方式发送消息至Monitor,Consumer和Provider会将信息存放在本地磁盘,平均1min会发送一次信息。Monitor在整个架构中是可选的(图中的虚线并不是可选的意思),Monitor功能需要单独配置,不配置或者配置以后,Monitor挂掉并不会影响服务的调用。

    二、dubbo原理

    本篇博客的内容总体上比较抽象,如果一个想马上使用dubbo的同学来说,读这篇博客效果不太好,本篇博客没有写怎么使用、配置dubbo,接下来,我再令写一篇dubbo入门包含demo的博客。

    I、初始化过程细节:
    上图中的第一步start,就是将服务装载容器中,然后准备注册服务。和Spring中启动过程类似,spring启动时,将bean装载进容器中的时候,首先要解析bean。所以dubbo也是先读配置文件解析服务。
    解析服务:
    1)、基于dubbo.jar内的Meta-inf/spring.handlers配置,spring在遇到dubbo名称空间时,会回调DubboNamespaceHandler类。
    2)、所有的dubbo标签,都统一用DubboBeanDefinitionParser进行解析,基于一对一属性映射,将XML标签解析为Bean对象。
    源码截图:
    在ServiceConfig.export 或者ReferenceConfig.get 初始化时,将Bean对象转会为url格式,将所以Bean属性转成url的参数。
    然后将URL传给Protocol扩展点,基于扩展点的Adaptive机制,根据URL的协议头,进行不同协议的服务暴露和引用。
    暴露服务:

    a、 只暴露服务端口

    在没有使用注册中心的情况,这种情况一般适用在开发环境下,服务的调用这和提供在同一个IP上,只需要打开服务的端口即可。
    即,当配置 or
    ServiceConfig解析出的URL的格式为:
    Dubbo://service-host/com.xxx.TxxService?version=1.0.0
    基于扩展点的Adaptiver机制,通过URL的“dubbo://”协议头识别,直接调用DubboProtocol的export()方法,打开服务端口。

    b、向注册中心暴露服务:

    和上一种的区别:需要将服务的IP和端口一同暴露给注册中心。
    ServiceConfig解析出的url格式为:
    registry://registry-host/com.alibaba.dubbo.registry.RegistryService?export=URL.encode(“dubbo://service-host/com.xxx.TxxService?version=1.0.0”)

    基于扩展点的Adaptive机制,通过URL的“registry://”协议头识别,调用RegistryProtocol的export方法,将export参数中的提供者URL先注册到注册中心,再重新传给Protocol扩展点进行暴露:
    Dubbo://service-host/com.xxx.TxxService?version=1.0.0

    引用服务:

    a、直接引用服务:

    在没有注册中心的,直连提供者情况下,
    ReferenceConfig解析出的URL格式为:
    Dubbo://service-host/com.xxx.TxxService?version=1.0.0

    基于扩展点的Adaptive机制,通过url的“dubbo://”协议头识别,直接调用DubboProtocol的refer方法,返回提供者引用。

    b、从注册中心发现引用服务:

    此时,ReferenceConfig解析出的URL的格式为:
    registry://registry-host/com.alibaba.dubbo.registry.RegistryService?refer=URL.encode(“consumer://consumer-host/com.foo.FooService?version=1.0.0”)

    基于扩展点的Apaptive机制,通过URL的“registry://”协议头识别,就会调用RegistryProtocol的refer方法,基于refer参数总的条件,查询提供者URL,如:
    Dubbo://service-host/com.xxx.TxxService?version=1.0.0

    基于扩展点的Adaptive机制,通过提供者URL的“dubbo://”协议头识别,就会调用DubboProtocol的refer()方法,得到提供者引用。
    然后RegistryProtocol将多个提供者引用,通过Cluster扩展点,伪装成单个提供这引用返回。

    三、远程调用细节:

    服务提供者暴露一个服务的详细过程:

    这里写图片描述

    上图是服务提供者暴露服务的主过程:
    首先ServiceConfig类拿到对外提供服务的实际类ref,然后将ProxyFactory类的getInvoker方法使用ref生成一个AbstractProxyInvoker实例,到这一步就完成具体服务到invoker的转化。接下来就是Invoker转换到Exporter的过程。
    Dubbo处理服务暴露的关键就在Invoker转换到Exporter的过程,下面我们以Dubbo和rmi这两种典型协议的实现来进行说明:
    Dubbo的实现:
    Dubbo协议的Invoker转为Exporter发生在DubboProtocol类的export方法,它主要是打开socket侦听服务,并接收客户端发来的各种请求,通讯细节由dubbo自己实现。
    Rmi的实现:
    RMI协议的Invoker转为Exporter发生在RmiProtocol类的export方法,他通过Spring或Dubbo或JDK来实现服务,通讯细节由JDK底层来实现。

    服务消费者消费一个服务的详细过程

    这里写图片描述

    上图是服务消费的主过程:
    首先ReferenceConfig类的init方法调用Protocol的refer方法生成Invoker实例。接下来把Invoker转为客户端需要的接口即可。



    展开全文
  • 拜托!面试请不要再问我Spring Cloud底层原理

    万次阅读 多人点赞 2019-02-27 14:53:23
    &gt;转载请标明出处:  &gt;...&gt;...&...本文为转载文章,作者:中华石杉,十余年BAT架构经验,倾囊相授。作者微信公众号:石杉的架构笔记(ID:shishan100) ...毫无疑问,Spring Cloud是目前微服务架构...

    >转载请标明出处: 
    >https://www.fangzhipeng.com
    > 本文出自[方志朋的博客](http://blog.csdn.net/forezp)

    >

    本文为转载文章,作者:中华石杉,十余年BAT架构经验,倾囊相授。作者微信公众号:石杉的架构笔记(ID:shishan100)

    概述

    毫无疑问,Spring Cloud是目前微服务架构领域的翘楚,无数的书籍博客都在讲解这个技术。不过大多数讲解还停留在对Spring Cloud功能使用的层面,其底层的很多原理,很多人可能并不知晓。因此本文将通过大量的手绘图,给大家谈谈Spring Cloud微服务架构的底层原理。

    实际上,Spring Cloud是一个全家桶式的技术栈,包含了很多组件。本文先从其最核心的几个组件入手,来剖析一下其底层的工作原理。也就是Eureka、Ribbon、Feign、Hystrix、Zuul这几个组件

     

    一、业务场景介绍

     

    先来给大家说一个业务场景,假设咱们现在开发一个电商网站,要实现支付订单的功能,流程如下:

     

    • 创建一个订单之后,如果用户立刻支付了这个订单,我们需要将订单状态更新为“已支付”

    • 扣减相应的商品库存

    • 通知仓储中心,进行发货

    • 给用户的这次购物增加相应的积分

     

    针对上述流程,我们需要有订单服务、库存服务、仓储服务、积分服务。整个流程的大体思路如下:

     

    • 用户针对一个订单完成支付之后,就会去找订单服务,更新订单状态

    • 订单服务调用库存服务,完成相应功能

    • 订单服务调用仓储服务,完成相应功能

    • 订单服务调用积分服务,完成相应功能

     

     

     

     

     

    至此,整个支付订单的业务流程结束

     

    下图这张图,清晰表明了各服务间的调用过程:

     

    好!有了业务场景之后,咱们就一起来看看Spring Cloud微服务架构中,这几个组件如何相互协作,各自发挥的作用以及其背后的原理。

     

    二、Spring Cloud核心组件:Eureka

     

    咱们来考虑第一个问题:订单服务想要调用库存服务、仓储服务,或者是积分服务,怎么调用?

     

    • 订单服务压根儿就不知道人家库存服务在哪台机器上啊!他就算想要发起一个请求,都不知道发送给谁,有心无力!

    • 这时候,就轮到Spring Cloud Eureka出场了。Eureka是微服务架构中的注册中心,专门负责服务的注册与发现。

     

     咱们来看看下面的这张图,结合图来仔细剖析一下整个流程: 

     

    如上图所示,库存服务、仓储服务、积分服务中都有一个Eureka Client组件,这个组件专门负责将这个服务的信息注册到Eureka Server中。说白了,就是告诉Eureka Server,自己在哪台机器上,监听着哪个端口。而Eureka Server是一个注册中心,里面有一个注册表,保存了各服务所在的机器和端口号

     

    订单服务里也有一个Eureka Client组件,这个Eureka Client组件会找Eureka Server问一下:库存服务在哪台机器啊?监听着哪个端口啊?仓储服务呢?积分服务呢?然后就可以把这些相关信息从Eureka Server的注册表中拉取到自己本地缓存起来。

     

    这时如果订单服务想要调用库存服务,不就可以找自己本地的Eureka Client问一下库存服务在哪台机器?监听哪个端口吗?收到响应后,紧接着就可以发送一个请求过去,调用库存服务扣减库存的那个接口!同理,如果订单服务要调用仓储服务、积分服务,也是如法炮制。

     

    总结一下:

     

    • Eureka Client:负责将这个服务的信息注册到Eureka Server中

    • Eureka Server:注册中心,里面有一个注册表,保存了各个服务所在的机器和端口号

     

    三、Spring Cloud核心组件:Feign

     

    现在订单服务确实知道库存服务、积分服务、仓库服务在哪里了,同时也监听着哪些端口号了。但是新问题又来了:难道订单服务要自己写一大堆代码,跟其他服务建立网络连接,然后构造一个复杂的请求,接着发送请求过去,最后对返回的响应结果再写一大堆代码来处理吗?

     

    这是上述流程翻译的代码片段,咱们一起来看看,体会一下这种绝望而无助的感受!!!

     

    友情提示,前方高能:

     

     

    看完上面那一大段代码,有没有感到后背发凉、一身冷汗?实际上你进行服务间调用时,如果每次都手写代码,代码量比上面那段要多至少几倍,所以这个事儿压根儿就不是地球人能干的。

      

    既然如此,那怎么办呢?别急,Feign早已为我们提供好了优雅的解决方案。来看看如果用Feign的话,你的订单服务调用库存服务的代码会变成啥样?

     

     

    看完上面的代码什么感觉?是不是感觉整个世界都干净了,又找到了活下去的勇气!没有底层的建立连接、构造请求、解析响应的代码,直接就是用注解定义一个 FeignClient接口,然后调用那个接口就可以了。人家Feign Client会在底层根据你的注解,跟你指定的服务建立连接、构造请求、发起靕求、获取响应、解析响应,等等。这一系列脏活累活,人家Feign全给你干了。

     

    那么问题来了,Feign是如何做到这么神奇的呢?很简单,Feign的一个关键机制就是使用了动态代理。咱们一起来看看下面的图,结合图来分析:

     

    • 首先,如果你对某个接口定义了@FeignClient注解,Feign就会针对这个接口创建一个动态代理

    • 接着你要是调用那个接口,本质就是会调用 Feign创建的动态代理,这是核心中的核心

    • Feign的动态代理会根据你在接口上的@RequestMapping等注解,来动态构造出你要请求的服务的地址

    • 最后针对这个地址,发起请求、解析响应

     

     

     

    四、Spring Cloud核心组件:Ribbon

     

    说完了Feign,还没完。现在新的问题又来了,如果人家库存服务部署在了5台机器上,如下所示:

     

    • 192.168.169:9000

    • 192.168.170:9000

    • 192.168.171:9000

    • 192.168.172:9000

    • 192.168.173:9000

     

    这下麻烦了!人家Feign怎么知道该请求哪台机器呢?

     

    这时Spring Cloud Ribbon就派上用场了。Ribbon就是专门解决这个问题的。它的作用是负载均衡,会帮你在每次请求时选择一台机器,均匀的把请求分发到各个机器上

     

     

     

     

    Ribbon的负载均衡默认使用的最经典的Round Robin轮询算法。这是啥?简单来说,就是如果订单服务对库存服务发起10次请求,那就先让你请求第1台机器、然后是第2台机器、第3台机器、第4台机器、第5台机器,接着再来—个循环,第1台机器、第2台机器。。。以此类推。

     

     此外,Ribbon是和Feign以及Eureka紧密协作,完成工作的,具体如下:

     

    • 首先Ribbon会从 Eureka Client里获取到对应的服务注册表,也就知道了所有的服务都部署在了哪些机器上,在监听哪些端口号。

    • 然后Ribbon就可以使用默认的Round Robin算法,从中选择一台机器

    • Feign就会针对这台机器,构造并发起请求。

     

    对上述整个过程,再来一张图,帮助大家更深刻的理解:

     

    五、Spring Cloud核心组件:Hystrix

     

    在微服务架构里,一个系统会有很多的服务。以本文的业务场景为例:订单服务在一个业务流程里需要调用三个服务。现在假设订单服务自己最多只有100个线程可以处理请求,然后呢,积分服务不幸的挂了,每次订单服务调用积分服务的时候,都会卡住几秒钟,然后抛出—个超时异常。

     

    咱们一起来分析一下,这样会导致什么问题?

     

    • 如果系统处于高并发的场景下,大量请求涌过来的时候,订单服务的100个线程都会卡在请求积分服务这块。导致订单服务没有一个线程可以处理请求

    • 然后就会导致别人请求订单服务的时候,发现订单服务也挂了,不响应任何请求了

     

    上面这个,就是微服务架构中恐怖的服务雪崩问题,如下图所示:

     

    如上图,这么多服务互相调用,要是不做任何保护的话,某一个服务挂了,就会引起连锁反应,导致别的服务也挂。比如积分服务挂了,会导致订单服务的线程全部卡在请求积分服务这里,没有一个线程可以工作,瞬间导致订单服务也挂了,别人请求订单服务全部会卡住,无法响应。

     

    但是我们思考一下,就算积分服务挂了,订单服务也可以不用挂啊!为什么?

     

    • 我们结合业务来看:支付订单的时候,只要把库存扣减了,然后通知仓库发货就OK了

    • 如果积分服务挂了,大不了等他恢复之后,慢慢人肉手工恢复数据!为啥一定要因为一个积分服务挂了,就直接导致订单服务也挂了呢?不可以接受!

       

    现在问题分析完了,如何解决?

     

    这时就轮到Hystrix闪亮登场了。Hystrix是隔离、熔断以及降级的一个框架。啥意思呢?说白了,Hystrix会搞很多个小小的线程池,比如订单服务请求库存服务是一个线程池,请求仓储服务是一个线程池,请求积分服务是一个线程池。每个线程池里的线程就仅仅用于请求那个服务。

     

    打个比方:现在很不幸,积分服务挂了,会咋样?

     

    当然会导致订单服务里的那个用来调用积分服务的线程都卡死不能工作了啊!但是由于订单服务调用库存服务、仓储服务的这两个线程池都是正常工作的,所以这两个服务不会受到任何影响。

     

    这个时候如果别人请求订单服务,订单服务还是可以正常调用库存服务扣减库存,调用仓储服务通知发货。只不过调用积分服务的时候,每次都会报错。但是如果积分服务都挂了,每次调用都要去卡住几秒钟干啥呢?有意义吗?当然没有!所以我们直接对积分服务熔断不就得了,比如在5分钟内请求积分服务直接就返回了,不要去走网络请求卡住几秒钟,这个过程,就是所谓的熔断!

     

    那人家又说,兄弟,积分服务挂了你就熔断,好歹你干点儿什么啊!别啥都不干就直接返回啊?没问题,咱们就来个降级:每次调用积分服务,你就在数据库里记录一条消息,说给某某用户增加了多少积分,因为积分服务挂了,导致没增加成功!这样等积分服务恢复了,你可以根据这些记录手工加一下积分。这个过程,就是所谓的降级。

     

    为帮助大家更直观的理解,接下来用一张图,梳理一下Hystrix隔离、熔断和降级的全流程:

     

    六、Spring Cloud核心组件:Zuul

     

    说完了Hystrix,接着给大家说说最后一个组件:Zuul,也就是微服务网关。这个组件是负责网络路由的。不懂网络路由?行,那我给你说说,如果没有Zuul的日常工作会怎样?

     

    假设你后台部署了几百个服务,现在有个前端兄弟,人家请求是直接从浏览器那儿发过来的。打个比方:人家要请求一下库存服务,你难道还让人家记着这服务的名字叫做inventory-service?部署在5台机器上?就算人家肯记住这一个,你后台可有几百个服务的名称和地址呢?难不成人家请求一个,就得记住一个?你要这样玩儿,那真是友谊的小船,说翻就翻!

     

    上面这种情况,压根儿是不现实的。所以一般微服务架构中都必然会设计一个网关在里面,像android、ios、pc前端、微信小程序、H5等等,不用去关心后端有几百个服务,就知道有一个网关,所有请求都往网关走,网关会根据请求中的一些特征,将请求转发给后端的各个服务。

     

    而且有一个网关之后,还有很多好处,比如可以做统一的降级、限流、认证授权、安全,等等。

     

    七、总结:

     

    最后再来总结一下,上述几个Spring Cloud核心组件,在微服务架构中,分别扮演的角色:

     

    • Eureka:各个服务启动时,Eureka Client都会将服务注册到Eureka Server,并且Eureka Client还可以反过来从Eureka Server拉取注册表,从而知道其他服务在哪里

    • Ribbon:服务间发起请求的时候,基于Ribbon做负载均衡,从一个服务的多台机器中选择一台

    • Feign:基于Feign的动态代理机制,根据注解和选择的机器,拼接请求URL地址,发起请求

    • Hystrix:发起请求是通过Hystrix的线程池来走的,不同的服务走不同的线程池,实现了不同服务调用的隔离,避免了服务雪崩的问题

    • Zuul:如果前端、移动端要调用后端系统,统一从Zuul网关进入,由Zuul网关转发请求给对应的服务

     

    以上就是我们通过一个电商业务场景,阐述了Spring Cloud微服务架构几个核心组件的底层原理。

     

    文字总结还不够直观?没问题!我们将Spring Cloud的5个核心组件通过一张图串联起来,再来直观的感受一下其底层的架构原理:

     

    如有收获,请帮忙转发,您的鼓励是作者最大的动力,谢谢!

    作者:中华石杉,十余年BAT架构经验,倾囊相授。个人微信公众号:石杉的架构笔记(ID:shishan100)

     

    ### 更多阅读

    [史上最简单的 SpringCloud 教程汇总](https://blog.csdn.net/forezp/article/details/70148833)

    [SpringBoot教程汇总](https://blog.csdn.net/forezp/article/details/70341818)

    [Java面试题系列汇总](https://blog.csdn.net/forezp/article/details/85163411)

     

                                              
                                                    扫一扫,支持下作者吧

                                    (转载本站文章请注明作者和出处 方志朋的博客

    展开全文
  • react底层原理解析之fiber

    万次阅读 2019-04-20 22:59:29
    Fiber的特点/作用 Fiber能够使得动画、布局和页面交互变得更加的流畅。 一:Fiber的概念   React Fiber是react执行渲染时的一种新的调度策略,JavaScript是单线程的,一旦组件开始更新,主线程就一直被React控制,...
  • Zookeeper底层原理分析

    千人学习 2019-05-20 14:04:14
    ZooKeeper 是一个 分布式 的,开放源码的分布式 应用程序协调服务 ,本课程主要对ZooKeeper的底层原理进行分析,主要包括Zookeeper原理,Zookeeper是如何解决数据一致性问题以及Zookeeper领导者选举原理等内容。
  • synchronized底层原理以及锁升级过程

    万次阅读 2020-05-17 22:01:52
    概念: synchronized是Java提供的一个并发控制的关键字,作用于对象上。主要有两种用法,分别是同步方法(访问对象和clss对象)和同步代码块(需要加入对象),保证了代码的原子性和可见性以及有序性,但是不会处理重...
  • HashMap底层原理

    2019-09-28 11:52:32
    HashMap底层原理
  • volatile 底层原理以及特性详解

    万次阅读 2020-06-09 20:40:22
    如果大家对java架构相关感兴趣,可以关注下面公众号,会持续更新java基础面试题, netty, spring boot,spring cloud等系列文章,一系列干货随时送达, 超神之路从此展开, BTAJ不再是梦想! 概念 1 volatile变量,用来...
  • Docker底层原理

    万次阅读 2020-02-10 19:11:49
    一、Docker是怎么工作的。 Docker是一个Client-Server结构的系统,Docker守护进程运行在主机上, 然后通过Socket连接从客户端访问,守护进程从客户端接受命令并管理运行在主机上的容器。 容器,是一个运行时环境,...
  • 欢迎加入java学习讨论群:725562382 CGLIB动态代理: CGLIB(Code Generation Library)是一个开源项目!是一个强大的,高性能,高质量的Code生成类库,它可以在运行期扩展Java类与实现Java接口。...
  • Spring Cloud底层原理

    万次阅读 2020-07-24 10:16:59
    本文先从其最核心的几个组件入手,来剖析一下其底层的工作原理。也就是Eureka、Ribbon、Feign、Hystrix、Zuul这几个组件。 一、业务场景介绍 先来给大家说一个业务场景,假设咱们现在开发一个电商网站,要实现支付...
  • React底层原理解析之diff算法

    万次阅读 2019-04-20 20:27:54
    React的diff算法是在哪里进行计算的? diff算法是在render里面进行计算的。 React的diff算法与传统的diff算法的区别: 传统的diff算法: 计算一棵树形结构转换为另一颗树形结构需要最少步骤,如果使用传统的diff算法...
  • HashMap底层是由哈希表实现的,是非常重要的数据结构,哈希表的基本结构就是“数组+链表”。 1:数组:占用空间连续,寻址容易,查询速度快,但是,增加和删除效率非诚低 2:链表:占用空间不连续,寻址困难,查询...
  • AOP底层原理解析

    万次阅读 2017-11-27 08:44:14
    1 什么是AOP: AOP AspectOrientedPrograming面向切面编程 AOP采取横向抽取机制,取代了传统纵向继承体系重复性代码(性能监视、事务管理、安全检查、缓存) Spring AOP使用纯Java实现,不需要专门的编译过程...
  • 深入讲解HashMap底层原理

    千人学习 2019-09-19 10:25:58
    【课程介绍】 本课程由业内技术大牛,经验丰富的讲师进行实战技术分享。 将带领大家深入理解HashMap的构造方法等源码底层实现原理,能够让学员逐步学会自己看源码
  • MD5算法底层原理

    万次阅读 2018-03-13 11:26:26
    MD5算法的过程分为四步:处理原文,设置初始值,循环加工,拼接结果。 第一步:处理原文 &nbsp;&nbsp;&...首先,我们计算出原文长度(bit)对512求余的结果,如果不等于448,就需要填充原文使得原文对512求...
  • synchronized 锁的底层原理

    万次阅读 2018-03-08 11:27:27
    版权声明:本文由施勇原创,转载请注明作者和出处! http://blog.csdn.net/shiyong1949/article/details/52643711log4j定义了8个级别的log(除去OFF和ALL,可以说分为...ALL最低等级的,用于打开所有日志记录。TRACE...
  • redis底层原理

    万次阅读 2017-11-30 17:17:20
    Redis对象类型简介 Redis是一种key/value型数据库,其中,每个key和value都是使用对象表示的。比如,我们执行以下代码: [plain] view plain copy print? redis>SET message "hello redis...而
  • Hadoop底层原理

    千次阅读 2019-12-12 08:32:01
    Hadoop底层原理 1.客户端执行hdfs fs put 本地文件系统中的文件路径 hdfs文件系统中的目录路径:hdfs fs put ./a.txt / 发送上传请求给namenode。 2.namenode根据元数据中的文件系统目录树 检测是否存在“该指定的...
  • String底层原理

    千次阅读 2018-12-11 13:24:08
    我问他 String的底层原理是什么 他思考了一会说不知道。 那么我们在面试的时候有可能会遇到类似的问题,怎么去解答,肯定是要去看String的源码的 public final class String implements java.io.Serializable, ...
  • springMVC 底层原理

    千次阅读 2019-11-15 12:16:50
    本文主要自定义实现解析springMVC底层如何实现@Controller,@RequestMapping等注解的,访问restURL如何基于反射执行到controller中相应方法的,以及执行完方法如何将结果返给前端。 package com.servlet; ...
  • volatile的底层原理与实现

    万次阅读 2020-10-24 13:01:55
    volatile的底层原理 volatile的两个作用: 可见性 防止指令重排序 计算机的组成 下图是一个典型的计算机结构图,计算机的组成主要包括CPU、存储器(内存)、IO(输入输出设备)。 存储器的层次结构 下图是计算机...
  • springcloud底层原理

    千次阅读 多人点赞 2018-12-14 10:36:57
    目录 一、业务场景介绍 二、Spring Cloud核心组件:Eureka 三、Spring Cloud核心组件:Feign 四、Spring Cloud核心组件:Ribbon 五、Spring Cloud核心组件:Hystrix ...六、Spring Cloud核心组件:Zuul ...
  • Lock锁底层原理

    万次阅读 多人点赞 2019-01-07 01:28:04
    当多个线程需要访问某个公共资源的时候,我们知道需要通过加锁来保证资源的访问不会出问题。java提供了两种方式来加锁, ...关于synchronized的原理可以阅读再有人问你synchronized是什么,就把这篇文章...
  • 理解spring事务底层原理

    千次阅读 2019-03-27 08:53:30
    常见数据库,这种策略遵从ACID原则,可以很好的保证业务的执行,spring事务底层可以使用tx命名空间实现,也可以通过Transactional注解的方式来实现,本文就讲下spring transactional注解底层的工作原理,要了解这个...
  • solr底层原理

    千次阅读 2018-06-11 10:41:17
    一、总论根据http://lucene.apache.org/java/docs/index.html定义:Lucene是一个高效的,基于Java的全文检索库。所以在了解Lucene之前要费一番工夫了解一下全文检索。那么什么叫做全文检索呢?这要从我们生活中的...
  • LinkedList底层原理

    千次阅读 2018-07-13 10:28:39
    如图所示 LinkedList 底层是基于双向链表实现的,也是实现了 List 接口,所以也拥有 List 的一些特点(JDK1.7/8 之后取消了循环,修改为双向链表)。新增方法 public boolean add(E e) { linkLast(e); return ...

空空如也

1 2 3 4 5 ... 20
收藏数 34,232
精华内容 13,692
关键字:

底层原理