褚成志的分享站

共享元对象，放到一个池子里面 池化思想，提前几个，重复利用， String使用的就是享元（常量池）s3.intern() 内部指向常量池的引用，****intern就能拿到常量池的引用 123456789101112131415public class TestString { public static void main(String[] args) { String s1 = "abc"; String s2 = "abc"; String s3 = new String("abc"); String s4 = new String("abc"); System.out.println(s1 == s2); //true System.out.println(s1 == s3); //false System.out.println(s3 == s4); //false ...

发生服务循环消费时候关闭服务启动检查默认情况下，若服务消费者先于服务提供者启动，则消费者端会报错。因为默认情况下消费者会在启动时查检其要消费的服务的提供者是否已经注册，若未注册则抛出异常。**在消费者端的 spring 配置文件中添加 ****check="false"**属性，则可关闭服务检查功能。 在循环消费场景下是必须要使用的。A 消费 B 服务，B 消费 C 服务，而 C 消费 A 服务。必须至少有一方要关闭服务检查功能，否则将无法启动任何一方。 多版本控制实现灰度发布系统升级采用的**“灰度发布（又称为金丝雀发布）” 是在低压力时段，让部分消费者先调用新的提供者实现类，其余的仍然调用老的实现类，在新的实现类运行没有问题的情况下，逐步让所有消费者全部调用成新的实现类。** 1234567<!--指定消费0.0.1版本，即oldService提供者--><!--<dubbo:reference id="someService" version="0.0.1"--> ...

为什么理解注册中心的必要性，就需要了解软件架构的发展历程。 系统架构的发展历程 为什么需要注册中心上面的微服务架构采用直连的方式，每一个机器都需要维护更新自己需要连接的机器的IP，将来地址出现变更，还需要及时更新。在集群内部的节点越来越多的时候，开发者管理起来将会非常混乱。此时加入注册中心，就无需将消费者和服务提供者绑定了，提供者宕机不会对消费者产生直接的影响，所有的机器只需要和注册中心去交互。服务方与注册中心之间通过“心跳”机制进行监控。实现服务的自动注册、发现、状态监控： 是什么注册中心一般会存放机器IP和URL之间的映射，并且在其客户端一般都会附带负载均衡的功能帮助用户开箱即用调用其他机器的服务。还会通过心跳机制实现服务的自动注册、发现、状态监控。 怎么用开源中间件zookeeper简单介绍最初是Hadoop的子项目，用来管理分布式中的集群。一般用作配置中心、注册中心、分布式锁 简单使用安装以及命令行的使用：https://juejin.cn/post/7025887917243383844 常见的客户端：Zookeeper Java客户端、Apache Curator...

1vim ~/.gitconfig 1234567891011121314151617 1 [user] 2 name = deltaqin 3 email = delta_qin@163.com 4 [core] 5 autocrlf = input 6 [alias] 7 co = checkout 8 br = branch 9 ci = commit 10 st = status 11 dog = log --all --decorate --oneline --graph 12 [http] 13 proxy = http://127.0.0.1:1087 14 [https] 15 proxy = http://127.0.0.1:1087~~ 12345git config --global alias.st status //status 缩写成 stgit config --global alias.co checkout //checkout 缩写成 cog...

在构建分布式消息系统时，我们面临的一个基本决策是确定数据流动的方向：消费者是从代理 (Broker) 拉取数据，还是由代理主动将数据推送给消费者。这一决策不仅影响系统的性能和效率，还决定了系统的架构和可扩展性。 推送 (Push) 模型的优势与局限 在 推送模型 中，数据流是由生产者主动向代理发送数据，随后代理根据预先设定的规则或策略，将数据推送给注册的消费者，这种模型的优点包括较低的延迟和实时性更强的数据传递。 然而，推送模型也有明显的局限性。 首先，它对网络带宽的要求较高，特别是在高并发的场景下，大量的小数据包频繁传输会导致网络拥塞。例如，消费者的消费能力为 10 条/s，而生产者生产能力为 100 条/s，此时会导致大量请求向下积压，当然，可以在 mq (Broker) 处进行消息堆积，或利用死信队列等机制进行退回，但是相应的，对于 Broker 的服务器压力也会显著增大。 其次，由于数据传输速率由代理控制，不同消费者之间的处理能力差异可能导致部分消费者无法及时处理接收到的数据，从而造成系统资源浪费或系统过载。 特别是当消费者的处理速度低于生产者的生...

问题提出：benchMark 性能测试，不修改原来代码，记录代码的运行时间： **继承实现：**类爆炸 **手动组合：**自己使用代理类包装，代理类里面调用被代理对象，附加上自己的事情。 实现同一个接口可以实现代理的嵌套，当需要实现多个代理功能的时候 限制就是要实现同一个接口 全能代理：不同接口，解耦，动态代理，运行时候生成。 **java.lang.reflect.Proxy **：通过反射getClass(Loader)，不需要读取源码，只需要二进制字节码就得到属性和方法。 被代理类需要有接口：代理遵循接口才能伪装为服务的对象，让外界调用接口即可，我们负责替换 cglib：底层也是asm。但是其实是生成了一个被代理类的子类，所以当一个类是final的时候，是不可以使用这个来实现代理的 asm：甚至可以代理final，因为直接修改二进制字节码，所以随意 注意字节码class文件是二进制的，使用IDE打开的时候是显示反编译之后的代码，其实不是文件真正存放的内容 静态代理–自己包装被包装和包装类都要实现一样的接口， 构造的时候都使用接口作为形参，传递实参的时...

Linux 存储媒介dev mount挂载和卸载存储设备管理存储设备的第一步是把设备连接到文件系统树中。这个叫做”挂载” 有一个叫做/etc/fstab 的文件可以列出系统启动时要挂载的设备。大多数文件系统是虚拟的，还有实际存在的硬盘分区 字段 内容 说明 1 设备名 2 挂载点 设备所连接到的文件系统树的目录。 3 文件系统类型 Linux 允许挂载许多文件系统类型。**大多数本地的 Linux 文件系统是 ext3， **但是也支持很多其它的，比方说 FAT16 (msdos), FAT32 (vfat)，NTFS (ntfs)，CD-ROM (iso9660)，等等。 4 选项 文件系统可以通过各种各样的选项来挂载。 5 频率 一位数字，指定是否和在什么时间用 dump 命令来备份一个文件系统。 6 次序 一位数字，指定 fsck 命令按照什么次序来检查文件系统。 1234567891011# 挂载在/dev/hdc的CD-ROM挂载到别的地方# 卸载的时候不要在要卸载的目录里面，否则 device is busy...

帮助文档是javadoc自动生成的，里面的内容都是源代码的注释有的东西，源代码是英文，文档有中文，可以文档和源码辅助一起看，更加清晰，看懂英语，也知道自己在哪个位置父类子类都有啥 有效读源码 5、解决方案。对于一些特定的问题，业界都是有一套成熟的解决方案的，一定要学到，这些是实打实在工作中会用到的。（举栗，分布式理论（事务，一致性算法，分布式锁），一致性Hash，负载均衡）还有就是。设计商品秒杀场景解决方案，缓存各种问题的解决方案，等等。。。 意义何在： 为什么这么写，设计模式 实现细节要画图 使用API时候的注意事项， 如何初始化 List、Map 及其 大小， 如何使用线程池设置合理，如何优雅使用锁， idea查看继承树https://jingyan.baidu.com/article/0bc808fc0f48661bd485b90c.html 源码查看（推荐）构建源码项目新建一个空的maven项目 将src.zip拷贝到项目的根目录，解压。 这样主要是为；了idea索引时间比较短，放在src里面索引时间太长了 注意同级目录： 设置源码为当前文件夹下的，不然不能...

依赖冲突的发现 现象一：一个类的行为不按照预期，本来这个类应该是有这个方法的，但是引入一个新的依赖之后就开始报错找不到方法了，一般就是依赖冲突的时候 Maven 自己选择了一个不符合自己预期的依赖导致报错。 依赖冲突的解决使用 Maven helper 找到对应类所在 jar 的依赖都由谁导入，之后排除掉不符合自己预期的依赖即可。 一般直接在插件右键就可以 exclude

书籍：https://jimmysong.io/kubernetes-handbook/ 容器–Cloud Native的基石容器最初是通过开发者工具而流行，可以使用它来做隔离的开发测试环境和持续集成环境，这些都是因为容器轻量级，易于配置和使用带来的优势，docker和docker-compose这样的工具极大的方便的了应用开发环境的搭建。 随着容器的在开发者中的普及，大家对CI流程的熟悉，容器周边的各种工具蓬勃发展，形成了一个小生态，涵盖了容器应用中从镜像仓库、服务编排、安全管理、持续集成与发布、存储和网络管理等各个方面，随着在单主机中运行容器的成熟，集群管理和容器编排成为容器技术亟待解决的问题。 Kubernetes–让容器应用进入大规模工业生产。Kubernetes是容器编排系统的事实标准 在单机上运行容器，无法发挥它的最大效能，只有形成集群，才能最大程度发挥容器的良好隔离、资源分配与编排管理的优势，而对于容器的编排管理，(Swarm、Mesos和Kubernetes) Kubernetes成为了无可争议的赢家。 Kubernetes的架构图显示了组件之间交互的接口CN...