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复用。如果一个服务器要处理多个服务或多个协议，

一、概述【1】Redis 是基于 Reactor模式开发的网络事件处理器：这个处理器被称为文件事件处理器（file event handler），这个文件事件处理器是单线程的，所以 Redis 才叫做单线程的模型：■ 文件事件处理器使用 I/O 多路复用（multiplexing）机制监听多个套接字 Socket，根据 Socket 上的事件来选择对应的事件处理器进行处理。■ 当被监听的套接字准备好执行连接应答（accept）、读取（read）、写入（write）、关闭（close）等操作时。与操作

AQS（AbstractQuenedSynchronizer 抽象队列同步器） 是一个用来构建锁和同步器的框架，使用 AQS能简单且高效地构造出应用广泛的大量的同步器，比如我们提到的ReentrantLock，Semaphore，其他的诸如 ReentrantReadWriteLock，SynchronousQueue，FutureTask等等皆是基于 AQS的。AQS是一种提供了原子式管理同步状态、阻塞和唤醒线程功能以及队列模型的简单框架。当然，我们自己也能利用 AQS非常轻松容易地构造出符合我们自己需求

ReentrantLock 支持公平锁和非公平锁，可重入锁 ReentrantLock的底层是通过 **AQS[链接]**实现。一、BAT 大厂的面试题**【1】**什么是可重入，什么是可重入锁? 它用来解决什么问题?【2】ReentrantLock 的核心是 AQS，那么它怎么来实现的，继承吗? 说说其类内部结构关系。【3】ReentrantLock 是如何实现公平锁的?【4】ReentrantLock 是如何实现非公平锁的?【5】ReentrantLock 默认实现的是公平还是非公平锁.

Synchronized原理分析加锁和释放锁的原理深入JVM看字节码，创建如下的代码：1 public class SynchronizedDemo2 {2 Object object = new Object();3 public void method1() {4 synchronized (object) {5 6 }7 }8 }使用 javac命令进行编译生成 .class文件>javac Synchronize

Reids 所有的数据结构都以唯一的 key 字符串作为名称，然后通过这个唯一的 key 值来获取相应的 value 数据。不同的数据结构差异就在于 value 的结构不一样。*一、*Redis 五大数据类型【1】String（字符串）：String 是 Redis 最基本的类型，一个 key 对应一个 value。String 类型是二进制安全的。意思是 Redis 的 String 可以包含任何数据。一个键最大能存储 512MB。【2】Hash（哈希）：Hash 是一个键值对集合，类似 Ja.

LRU（Least Recently Used：最近最少使用）：简单的说，就是保证基本的 Cache容量，如果超过容量则必须丢掉最不常用的缓存数据，再添加最新的缓存。每次读取缓存都会改变缓存的使用时间，将缓存的存在时间重新刷新。其实，就是清理缓冲的一种策略。我们可以通过双向链表的数据结构实现 LRU Cache，链表头（head）保存最新获取和存储的数据值，链表尾（tail）既为最不常使用的值，当需要清理时，清理链表的 tail 即可，并将前一个元素设置为tail。结构图如下：[外链图片转存失败,源站可

查询的生命周期大致可以按照顺序来看：从客户端到服务端，然后在服务器上进行解析，生成执行计划，执行，并返回结果给客户端。其中 “执行” 可以认为是整个生命周期中最重要的阶段，其中包括了大量为了检索数据到存储引擎的调用以及调用后的数据处理，包括排序分组等。当希望 MySQL 能够以高性能的方式运行查询时，最好的办法就是弄清楚 MySQL 是如何优化和执行查询的。MySQL 执行一个查询的过程，如下：【1】首先我们会连接到这个数据库上，这时候接待你的就是连接器。连接器负责跟客户端建立连接、获取权限、维持和管理

前言MyBatis是常见的Java数据库访问层框架。在日常工作中，开发人员多数情况下是使用MyBatis的默认缓存配置，但是MyBatis缓存机制有一些不足之处，在使用中容易引起脏数据，形成一些潜在的隐患。个人在业务开发中也处理过一些由于MyBatis缓存引发的开发问题，带着个人的兴趣，希望从应用及源码的角度为读者梳理MyBatis缓存机制。本次分析中涉及到的代码和数据库表均放在GitHub上，地址： mybatis-cache-demo 。目录本文按照以下顺序展开。一级缓存介绍及相关配置。一

Mybatis 的整体架构分为三层，分别是基础支持层、核心处理层和接口层。基础支持层为核心处理层的功能提供了良好的支撑。一、接口层在不与 Spring 集成的情况下，使用 MyBatis 执行数据库的操作主要如下：InputStream is = Resources.getResourceAsStream("myBatis-config.xml");SqlSessionFactoryBuilder builder = new SqlSessionFactoryBuilder();SqlSess

NIO（Non-blocking I/O，在Java领域，也称为New I/O），是一种同步非阻塞的I/O模型，也是 I/O多路复用的基础，已经被越来越多地应用到大型应用服务器，成为解决高并发与大量连接、I/O处理问题的有效方式。那么NIO的本质是什么样的呢？它是怎样与事件模型结合来解放线程、提高系统吞吐的呢？本文会从传统的阻塞I/O和线程池模型面临的问题讲起，然后对比几种常见 I/O模型，一步步分析NIO怎么利用事件模型处理I/O，解决线程池瓶颈处理海量连接，包括利用面向事件的方式编写服务端/客户