java知识点高效记忆汇总_java概念性的知识怎么背-CSDN博客

本文链接：https://blog.csdn.net/qq_45738250/article/details/126398241

第一章 Java基础

一、java基础

1.HashMap结构

1.1 知识点：

数组默认长度16，扩容因子12，当有冲突就转为链表，链表长度超过8就转变为红黑树，或者数组长度达到64也会转变为红黑树。

1.2 高效记忆：

数组里石榴(16)扩(扩容因子)散的香味吸引了蚁儿(12)来吃，越来越多的蚁儿形成链(链表)条一样长，戴上眼镜(8)仔细看的话，蚁儿聚集起来后像螺丝(64)转呀转，转成了一颗树(红黑树)。

1.2 运用方法：

数字编码法：16、12、8
抽字串联法、故事串联法

二、jvm

3.jvm体系结构

高效记忆：
（1）头发：头上的假发（.java File）被发卡（.class File）卡得非常热（class loader）
（2）眼睛：眼睛看到很多深圳本地（**本地方法栈）**人站（栈）在大街上，人多的计数器（计数器）都算不过来，原来是周杰伦来深圳开演唱会了！
（3）耳朵：耳朵没有办法（方法区）听到外面的声音，因为房子是全部用隔音墙堆（堆）的。
（4）鼻子：我的鼻子直接（直接内存）闻到了很远（元数据区）的烧鹅的味道，太香了！
（5）嘴巴：我用本地方法（本地方法库）的吃烧鹅，然后直接口（本地方法接口）吃了，最后无法执行（执行引擎）今天的演讲任务了。
在这里插入图片描述

4. 类加载流程图

高效记忆：类加载流程

（1）今天我太无聊了，于是下载（加载）了抖音安装包，安装抖音的时候，手机会先验证（验证）安装包的安全性。

（2）安装好后抖音会做好自启动、开启定位等准备（准备），然后会解析（解析）我的用户名和密码等信息，最后初始化（初始化）信息。

（3）当我使用（使用）一天后觉得浪费了太多时间，于是又把抖音卸载（卸载）了。

上述可以结合自己对具体过程联合记忆，如：

加载：加了2个擂（2进制类）台，擂台上东西堆成了卡车模特队形象。（class对象）

验证：验证文件格式中是否有字节码、引用符号

准备：准备嫁给变态（静态变量）却被默认（初始默认值）了

解析：引用符号直接引用

初始化：变态被赋予正确的初始价值

在这里插入图片描述

6. 类加载器

高效记忆：类加载分类

我引导（引导类加载器）爸妈扩展了（扩展类加载器）微信聊天应用（应用类加载器）的用户自定义表情（用户自定义类加载器）。

7. 双亲委派工作原理

高效记忆：双亲委派原理

（1）子类（类加载器）班级学生会收到校外联谊请求（类加载请求）访问后，不是自己班级学生会先去决定并执行（加载执行）接待，而是先委托给父类（父类加载器）系级学生会去决定接待，

（2）如果父类（父类加载器）系级学生会还有父类（父类加载器）院级学生会，则进一步向上委托，直到顶级父类（顶级类加载器）总学生会。

（3）父类（父类加载器）总学生会决定接待后，如果需要父类（父类加载器）总学生会执行接待，就由父类（父类加载器）总学生会直接执行接待

（4）如果父类（父类加载器）总学生会不需要亲自执行接待，则让他子类（子类加载器）院级学生会去执行接待。

7.1 一个类加载器收到类加载请求后并不会自己先去加载，而是把请求委托给父类的加载器去执行

7.2 如果父类加载器还存在其父类加载器，则进一步向上委托直到顶级类加载器，

7.3 如果父类加载器完成类加载，就成功返回

7.4 如果父类加载器未完成类加载，其子类加载器就会去加载。

8. 运行时数据区域

（1）Java 程序在运行时，会为 JVM 单独划出一块内存区域。
（2）这块内存区域又可以再次划分出一块运行时数据区，含以下五个部分：
在这里插入图片描述

高效记忆：JVM运行区数据类型

（1）我在客栈（栈）里的8（局部变量的8大基本数据类型）个对象饮用（对象引用）青梅煮酒，

（2）因为不讲究喝酒方法（方法区）醉的一塌糊涂，最后都变态（静态变量）地躺在敞亮水池（常量、运行时常量池）中，累的没有办法起来（类、方法），

（3）等我醒来发现，前面都是我堆（堆）集的梦里new出来的对象（new的对象实例）

9.垃圾收集器

（1）单行程（单线程）的Siri（serial）老（serial old）了，收集信息速度太慢了，于是派来了新（ ParNew）的多行程的语音助手来帮忙。
（2）可是收集量还是不够大，于是又派来了斯克文（Parallel Scavenge）提高收集量，而且和之前派来了老（parallel Old）的一起收集很合拍。
（3）收集量越来越多累得他们不得不停顿休息。还好西姆斯（CMS）也来帮忙收集了。
而且他不仅停顿休息少而且收集量也大，只是有一点，收集完比较多碎片化的东西。
不过他找到朋友G1来帮他解决了这个问题。

10. jvm调优

（1）使用收集器（选择合适收集器）时根据大对象标准（调整大对象标准）去调整内存大小（调整内存、本地内存大小）、比率（调整内存比率）

（2）调整停顿时间（设置符合预期的停顿时间）以触发（设置合适的GC触发时机）对象升级老年代（调整对象升级老年代年龄）

11.jvm启动参数：

高效记忆：jvm配置参数

（1）这个星期天上午，衣物堆内存（堆内存）在很多需要使用算法机洗（GC算法）的衣服，而且因为衣服太多了，所以需要几台洗衣机并行机洗（GC并行线程数）。
（2）中午终于洗完衣服了衣服，觉得很有成就感，于是我写下了巨大的日志（GC日志）并保存在日志文件（GC日志文件）夹中。
（3）但是日志文件超过了原数据区域的最大值（元数据区的最大值），于是我压缩了单个日志形成文件占用大小（单个线程栈的大小），并设置之后如果内存溢出自动转存（堆内存溢出自动进行dump）云端。
在这里插入图片描述

12.jvm的相关命令工具：

高效记忆：jvm命令

（1）先用jps列出进程，再用jstat打印状态，然后再使用jinfo查看信息，
（2）其次再用jmap堆转存快照，以及用jstack转存当前线程快照，最后用jhat查看堆内存快照。
（3）实战cpu飙升：
a.先用top后用shift+p找到占用CPU最高的进程，再用top -p 进程号后用H找到占用cpu最高的线程，
b.再执行jstack 线程号输出线程信息，同时根据线程号转成的16进制找到对应的堆信息，然后再找到对应的代码

第二章 SpringCloud

一、微服务

1. 微服务理解

1.1 核心思想服务拆分与解耦，降低复杂性。
1.2 强调将功能合理拆解，按照单一责任原则明确角色，尽可能保证每个服务的功能单一。
1.3 各个服务做到灵活、可复用。
1.4 各个服务可以根据自身资源需求，单独部署及横向扩展。

高效记忆：微服务理解—调整公司组织架构

（1）这个月公司调整组织架构，核心思想是服务组织拆分与解耦，降低服务组织复杂性
（2）CEO强调将组织合理拆解，按照单一责任原则明确角色，尽可能保证每个服务组织的功能单一
（3）各个服务组织做到灵活、可复用
（4）各个服务组织可以根据自己资源需求，单独部署及横向扩展

2.单体改成微服务

2.1 需要各个功能模块服务化，就是将单体应用通过架包依赖方法调用，改成通过RPC接口远程调用的方式。
2.2 先把业务及边界梳理清楚，
2.3 新的需求放到微服务，老的业务及模块按照优先级和重要程度一点点从单体迁移到微服务，
2.4 微服务上线后渐渐取代老的单体，等全部迁移完毕上线稳定后，就可以下线老的单体应用。

高效记忆：单体改成微服务—搬家

（1）这个月要搬家了，先将各个模块细化，（将单体应用通过架包依赖方法调用，改成通过RPC接口远程调用的方式。
（2）先把房子模块（服务的业务、模块）及边界梳理清楚
（3）新的需要（需求）东西放到新房子（微服务），老的模块（业务及模块）按照优先级和重要程度一点点从老房子（单体）迁移到新房子（微服务）
（4）新房子（微服务）入住（上线）后取代老房子（老的单体），等全部迁移完毕入住（上线）稳定后，就可以离开（下线）老房子（老的单体应用）。

第三章 Spring及SpringBoot

一、Spring

1.Spring应用文之刷新源码

高效记忆：Spring应用文刷新 — 刷机

（1）手机系统太卡了于是自己刷机。首先 准备刷机环境 （准备刷新上下文环境），准备好后老系统 初始化并加载 定义信息（初始化BeanFactory，并加载bean definitions信息）

（2）然后进行系统配置并（对beanFacotry进行配置）开始系统激活并提交过程（激活BeanFactoryPostProcessors）

（3）再进行验证码注册并提交过程（注册BeanPostProcessors），之后新系统 初始化信息资源、广播 且注册监听器（初始化MessageSource、初始化事件广播器、注册事件监听器）

（4）最后系统 热加载弹粒 并（构造热加载单例bean）完成刷机 （完成刷新过程,通知生命周期处理器），如果刷机错误就 销户并修改 激活标识（销毁bean、修改active标识）

```java
	@Override
	public void refresh() throws BeansException, IllegalStateException {
		synchronized (this.startupShutdownMonitor) {
			// Prepare this context for refreshing.
			prepareRefresh();   // #1 准备刷新上下文环境

			// Tell the subclass to refresh the internal bean factory.
			ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory(); // #2 初始化BeanFactory，并加载bean definitions信息

			// Prepare the bean factory for use in this context.
			prepareBeanFactory(beanFactory);    // #3 对beanFacotry进行配置

			try {
				// Allows post-processing of the bean factory in context subclasses.
				postProcessBeanFactory(beanFactory);    // #4  提供给子类扩展的预留方法

				// Invoke factory processors registered as beans in the context.
				invokeBeanFactoryPostProcessors(beanFactory);   // #5 激活BeanFactoryPostProcessors

				// Register bean processors that intercept bean creation.
				registerBeanPostProcessors(beanFactory);    // #6 注册BeanPostProcessors

				// Initialize message source for this context.
				initMessageSource();    // #7 初始化MessageSource

				// Initialize event multicaster for this context.
				initApplicationEventMulticaster();  // #8 初始化事件广播器

				// Initialize other special beans in specific context subclasses.
				onRefresh();    // #9 提供给子类初始化其他的Bean

				// Check for listener beans and register them.
				registerListeners();    // #10 注册事件监听器

				// Instantiate all remaining (non-lazy-init) singletons.
				finishBeanFactoryInitialization(beanFactory);   // #11 构造热加载单例bean

				// Last step: publish corresponding event.
				finishRefresh();    // #12 完成刷新过程,通知生命周期处理器
			}

			catch (BeansException ex) {
				if (logger.isWarnEnabled()) {
					logger.warn("Exception encountered during context initialization - " +
							"cancelling refresh attempt: " + ex);
				}

				// Destroy already created singletons to avoid dangling resources.
				destroyBeans(); // #13 出错了，销毁bean

				// Reset 'active' flag.
				cancelRefresh(ex);  // #14 出错了，修改active标识

				// Propagate exception to caller.
				throw ex;
			}

			finally {
				// Reset common introspection caches in Spring's core, since we
				// might not ever need metadata for singleton beans anymore...
				resetCommonCaches();
			}
		}
	}
```