失铭的笔记

Nacos-sever Nacos官网介绍中说明：Nacos: 一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。 我所在的公司所用的也是nacos，我的毕业设计我也准备使用nacos来作为注册中心。今天便研究了一下Nacos-server，总结了一下Nacos-server如何启动和部署。 nacos官方提供两种下载方式，一种是源码，一种是压缩包。 源码方式 下载源码 1git clone https://github.com/alibaba/nacos.git 用idea打开nacos文件夹 修改启动方式 如下图所示，打开concole目录下nacos文件，创建”Nacos”启动配置 修改VM options 1234# -Dnacos.home可以不设 ...

本文转自Java CAS 和 ABA 问题 Java CAS 和 ABA 问题 独占锁：是一种悲观锁，synchronized 就是一种独占锁，会导致其它所有需要锁的线程挂起，等待持有锁的线程释放锁。 乐观锁：每次不加锁，假设没有冲突去完成某项操作，如果因为冲突失败就重试，直到成功为止。 CAS 操作乐观锁用到的机制就是 CAS，Compare and Swap。 CAS 有 3 个操作数，内存值 V，旧的预期值 A，要修改的新值 B。当且仅当预期值 A 和内存值 V 相同时，将内存值 V 修改为 B，否则什么都不做。 非阻塞算法 （nonblocking algorithms） 一个线程的失败或者挂起不应该影响其他线程的失败或挂起的算法。 现代的 CPU 提供了特殊的指令，可以自动更新共享数据，而且能够检测到其他线程的干扰，而 compareAndSet() 就用这些代替了锁定。 AtomicInteger 示例拿 AtomicInteger 来研究在没有锁的情况下是如何做到数据正确性的。 1private volatile int value; 在没有锁的机制下需要借 ...

多级缓存为什么需要 CPU cache?CPU 的频率太快了，快到主存跟不上，这样在处理器时钟周期内，CPU 常常需要等待主存，浪费资源，所以 cache 的出现，是为了缓解 CPU 和内存之间速度的不匹配问题（结构：cpu->cache->memort） cache 工作原理cache 的工作原理是基于“局部性”原理，它包含以下两个方面： 时间局部性：如果某个数据被访问，那么在不久的将来他很可能被再次访问 空间局部性：如果某个数据被访问，那么与他相邻的数据很快也可能被访问 多级缓存是什么左图为最简单的高速缓存的配置，数据的读取和存储都经过高速缓存，CPU 核心与高速缓存有一条特殊的快速通道；主存和高速缓存都连在系统总线上，这条总线还用于其他组件的通信。高速缓存出现不久，系统变得越来越复杂，高速缓存与主存之间的速度差异被拉大，直到加入了另一级缓存，新加入的这级缓存比第一缓存更大，而且更慢，而且经济上不合适，所以有了二级缓存，甚至是三级缓存。 cache 带来的问题cache 给系统带来性能上飞跃的同时，也引入了新的问题“缓存一致性问题”。设想如下场景（cpu 一共有两 ...

本文转自java 线程池总结 线程池 池化技术的思想主要是为了减少每次获取资源的消耗，提高对资源的利用率。 线程池提供了一种限制和管理资源（包括执行一个任务）。 每个线程池还维护一些基本统计信息，例如已完成任务的数量。 这里借用《Java 并发编程的艺术》提到的来说一下使用线程池的好处： 降低资源消耗。通过重复利用已创建的线程降低线程创建和销毁造成的消耗。 提高响应速度。当任务到达时，任务可以不需要的等到线程创建就能立即执行。 提高线程的可管理性。线程是稀缺资源，如果无限制的创建，不仅会消耗系统资源，还会降低系统的稳定性，使用线程池可以进行统一的分配，调优和监控。 Executor 框架简介Executor 框架是 Java5 之后引进的，在 Java 5 之后，通过 Executor 来启动线程比使用 Thread 的 start 方法更好，除了更易管理，效率更好（用线程池实现，节约开销）外，还有关键的一点：有助于避免 this 逃逸问题。 补充：this 逃逸是指在构造函数返回之前其他线程就持有该对象的引用. 调用尚未构造完全的对象的方法可能引发令人疑惑的错误。 Ex ...

类加载机制JVM 把 class 文件加载到内存，并对数据进行校验、准备、解析、初始化，最终形成 JVM 可以直接使用的 Java 类型的过程。 图片来自【Java 基础】类加载过程 加载将 class 字节码文件加载到内存中，并将这些数据转换成方法区中的运行时数据（静态变量、静态代码块、常量池等），在堆中生成一个 Class 类对象代表这个类（反射原理），作为方法区类数据的访问入口。 链接将 Java 类的二进制代码合并到 JVM 的运行状态之中。 验证确保加载的类信息符合 JVM 规范，没有安全方面的问题。 准备正式为类变量(static 变量)分配内存并设置类变量初始值的阶段，这些内存都将在方法区中进行分配。注意此时的设置初始值为默认值，具体赋值在初始化阶段完成。 解析虚拟机常量池内的符号引用替换为直接引用（地址引用）的过程。 初始化初始化阶段是执行类构造器<clinit>()方法的过程。类构造器<clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块(static 块)中的语句合并产生的。 当初始化一个类的时候，如果发现其 ...

本博客大部分内容来于免费在线学习设计模式 1：访问者模式访问者模式是一种行为设计模式， 它能将算法与其所作用的对象隔离开来。 2：访问者模式问题假如你的团队开发了一款能够使用巨型图像中地理信息的应用程序。图像中的每个节点既能代表复杂实体（例如一座城市），也能代表更精细的对象（例如工业区和旅游景点等）。如果节点代表的真实对象之间存在公路，那么这些节点就会相互连接。在程序内部，每个节点的类型都由其所属的类来表示，每个特定的节点则是一个对象。 一段时间后，你接到了实现将图像导出到 XML 文件中的任务。这些工作最初看上去非常简单。你计划为每个节点类添加导出函数，然后递归执行图像中每个节点的导出函数。解决方案简单且优雅：使用多态机制可以让导出方法的调用代码不会和具体的节点类相耦合。 但是架构师拒绝批准对已有节点类进行修改。他认为这些代码已经是产品了，不想冒险对其进行修改，因为修改可能会引入潜在的缺陷。他还质疑在节点类中包含导出 XML 文件的代码是否有意义。这些类的主要工作是处理地理数据。导出 XML 文件的代码放在这里并不合适。还有另一个原因，那就是在此项任务完成后， 营销部门很有可能会 ...

本博客大部分内容来于免费在线学习设计模式 1：模板方法模式模板方法模式是一种行为设计模式，它在超类中定义了一个算法的框架，允许子类在不修改结构的情况下重写算法的特定步骤。 2：模板方法问题在面向对象程序设计过程中，程序员常常会遇到这种情况：设计一个系统时知道了算法所需的关键步骤，而且确定了这些步骤的执行顺序，但某些步骤的具体实现还未知，或者说某些步骤的实现与具体的环境相关。 例如，去银行办理业务一般要经过以下4个流程：取号、排队、办理具体业务、对银行工作人员进行评分等，其中取号、排队和对银行工作人员进行评分的业务对每个客户是一样的，可以在父类中实现，但是办理具体业务却因人而异，它可能是存款、取款或者转账等，可以延迟到子类中实现。 这样的例子在生活中还有很多，例如，一个人每天会起床、吃饭、做事、睡觉等，其中“做事”的内容每天可能不同。我们把这些规定了流程或格式的实例定义成模板，允许使用者根据自己的需求去更新它，例如，简历模板、论文模板、Word 中模板文件等。 3：模板方法解决方案模板方法模式建议将算法分解为一系列步骤，然后将这些步骤改写为方法，最后在 “模板方法” 中依次调用这些方 ...

本博客大部分内容来于免费在线学习设计模式 1：策略模式策略模式是一种行为设计模式， 它能让你定义一系列算法， 并将每种算法分别放入独立的类中， 以使算法的对象能够相互替换。 2：策略模式问题你设计了一款地图程序。我相信大家都用过地图app，而这些程序中提供了多种策略来进行导航。步行，公交车，地铁，骑行，自驾等多种方法。如果将这些算法全部写在一个类中，这个类的体积臃肿，对某个算法进行任何修改都会影响整个类，从而增加在已有正常运行代码中引入错误的风险。同时将花费大量时间在合并冲突上。 3：策略模式解决方案策略模式建议找出负责用许多不同方式完成特定任务的类， 然后将其中的算法抽取到一组被称为策略的独立类中。 名为上下文的原始类必须包含一个成员变量来存储对于每种策略的引用。上下文并不执行任务，而是将工作委派给已连接的策略对象。上下文不负责选择符合任务需要的算法——客户端会将所需策略传递给上下文。实际上，上下文并不十分了解策略，它会通过同样的通用接口与所有策略进行交互，而该接口只需暴露一个方法来触发所选策略中封装的算法即可。 因此，上下文可独立于具体策略。这样你就可在不修改上下文代码或其他策 ...

本博客大部分内容来于免费在线学习设计模式 1：状态模式状态模式是一种行为设计模式，让你能在一个对象的内部状态变化时改变其行为，使其看上去就像改变了自身所属的类一样。 2：状态模式问题状态模式与有限状态机的概念紧密相关。其主要思想是程序在任意时刻仅可处于几种有限的状态中。在任何一个特定状态中，程序的行为都不相同，且可瞬间从一个状态切换到另一个状态。不过，根据当前状态，程序可能会切换到另外一种状态，也可能会保持当前状态不变。这些数量有限且预先定义的状态切换规则被称为转移。 对这种有状态的对象编程，传统的解决方案是：将这些所有可能发生的情况全都考虑到，然后使用 if-else 或 switch-case 语句来做状态判断，再进行不同情况的处理。但是显然这种做法对复杂的状态判断存在天然弊端，条件判断语句会过于臃肿，可读性差，且不具备扩展性，维护难度也大。且增加新的状态时要添加新的 if-else 语句，这违背了“开闭原则”，不利于程序的扩展。 3：状态模式解决方案状态模式建议为对象的所有可能状态新建一个类，然后将所有状态的对应行为抽取到这些类中。 原始对象被称为上下文（context），它 ...

本博客大部分内容来于免费在线学习设计模式 1：备忘录模式备忘录模式是一种行为设计模式， 允许在不暴露对象实现细节的情况下保存和恢复对象之前的状态。 2：备忘录模式问题在我们的日常生活中，撤销操作已经是每个编辑程序不可或缺的一部分了。一个程序如果没有撤销的能力。对于这一程序的用户体验将造成极大影响。那么撤销功能怎么实现呢？你选择采用直接的方式来实现该功能：程序在执行任何操作前会记录所有的对象状态，并将其保存下来。当用户此后需要撤销某个操作时，程序将从历史记录中获取最近的快照，然后使用它来恢复所有对象的状态。 如何生成一个快照呢？你需要遍历对象的所有成员变量并将其数值复制保存。但只有当对象对其内容没有严格访问权限限制的情况下，你才能使用该方式。不过很遗憾，绝大部分对象会使用私有成员变量来存储重要数据，这样别人就无法轻易查看其中的内容。 现在先暂时忽略这个问题，假设所有对象的成员变量都可以任意访问。这样你可以随时生成对象快照，但是这里还有另外一个很严重的问题-未来你可能添加一些成员变量，那么你将不得不对负责复制受影响对象状态的类进行更改 还有更多问题。让我们来考虑编辑器（Editor）状 ...