m0_37235955的博客

我是小号，找我大号。

观察者模式定义了对象之间的一对多依赖，这样一来，当一个对象改变时，他的所有依赖者都会收到通知并自动更新。类图主题与观察者之间松耦合当两个对象之间松耦合，它们依然可以交互，但是不太清楚彼此的细节。观察者模式提供了一种对象设计，让主题和观察者之间松耦合。关于观察者的一切，主题只知道观察者实现了某个接口（也就是Observer接口）。主题不需要知道观察者的具体类是谁、做了些什么或其他任何细节。任何时候我们都可以增加新的观察者。

Head First设计模式》使用鸭子举例，从一开始简单的封装实现鸭子游泳、叫的行为，到后来行为的添加之后导致现有设计的弹性不足（可复用、可扩展、可维护能力大大折扣），作者将OO基础&原则结合起来，设计一个应对鸭子行为添加时弹性较大的系统，这种模式称之为策略模式。首先考虑利用接口定义行为，特殊的鸭子实现特定的接口，来达到具备某种能力的目的。而最终的这个系统运用的就是策略模式，它将算法族与使用算法的客户独立开来，可以相互替换（我可以在运行时让鸭子会叫，也可以让它不会叫）如果产品要求有的鸭子是会飞的。

【代码】【每天一道算法题】day2-选择排序。

一个操作如果和样本的数据量没有关系，每次都是固定时间内完成的操作，叫做常数操作。时间复杂度为一个算法流程中，常数操作数量的一个指标。常用O(读作big O)来表示。具体来说，先要对一个算法流程非常熟悉，然后去写出这个算法流程中，发生了多少常数操作，进而总结出常数操作数量的表达式。评价一个算法流程的好坏，先看时间复杂度的指标，然后再分析不同数据样本下的实际运行时间，也就是“常数项时间”。，剩下的部分如果为f(N)，那么时间复杂度为O(f(N))。

【代码】每天一道算法题code1-数组，给定一个数组，表示连续n天的股价，数组下标表示第几天。

一、概述死锁是指两个或两个以上的进程在执行过程中，因争抢资源而造成的一种互相等待的现象，若无外力干涉它们将无法推进，如果系统资源充足，进程的资源请求能够得到满足，死锁出现的可能性就很低，否则就会因争夺有限的资源而陷入死锁。死锁产生的原因：【1】系统资源不足；【2】资源分配不当；【3】进程运行推进的顺序不合适；形成死锁的四个必要条件：**【1】互斥条件：**一个资源每次只能被一个进程使用。**【2】请求与保持条件：**一个进程因请求资源而阻塞时，对已获得的资源保持不放。**【3】不剥夺条件：*

了解一些 RabbitMQ 的实现原理也是很有必要的，它可以让你在遇到问题时能透过现象看本质。比如一个队列的内部存储其实是由5个子队列来流转运作的，队列中的消息可以有4种不同的状态等，通过这些可以明白在使用 RabbitMQ 时尽量不要有过多的消息堆积，不然会影响整体服务的性能。存储机制RabbitMQ存储层包含两个部分：队列索引和消息存储。RabbitMQ消息有两种类型：持久化消息和非持久化消息，这两种消息都会被写入磁盘。持久化消息在到达队列时写入磁盘，同时会内存中保存一份备份，当内存吃紧时.

Spring Cloud Ribbon 是一个基于 HTTP 和 TCP 的客户端负载均衡工具。可以将面向服务的 REST 模板请求自动转化成客户端负载均衡的服务调用。Spring Cloud Ribbon 虽然是一个工具类框架，但它不像服务注册中心、配置中心、API网关那样需要独立部署。但是它几乎存在于每一个 Spring Cloud 构建的微服务和基础设置中。因为微服务间的调用，API 网关的请求转发等内容，实际上都是通过 Ribbon 来实现的，包括 Feign 它也是基于 Ribbon 实现的工具。

IO多路复用之select、poll、epoll详解IO多路复用是指内核一旦发现进程指定的一个或者多个IO条件准备读取，它就通知该进程。IO多路复用适用如下场合：当客户处理多个描述符时（一般是交互式输入和网络套接口），必须使用I/O复用。当一个客户同时处理多个套接口时，而这种情况是可能的，但很少出现。如果一个TCP服务器既要处理监听套接口，又要处理已连接套接口，一般也要用到I/O复用。如果一个服务器即要处理TCP，又要处理UDP，一般要使用I/O复用。如果一个服务器要处理多个服务或多个协议，