先获取对象存入clazz中，利用识别类是否含有特定的注解（也就是识别注解名）再实例化，一个类中会有很多个标签所以先用数组将类的标签存入，接着遍历找到我们需要注解，再获取注解里的属性存入容器中，这个属性通常就是需要调用的方法的路径。在web容器中我们不会像平常使用new来实现类的实例化，这里通过Java的反射来获取类对象，通过Class获取构造方法实时创建对象。这里的存入容器，这一步也和tomcat

性能上，利用 Reactive 并行加载和多级缓存突破了 I/O 瓶颈。智能上，依靠 LLM 提炼记忆、决策工具，实现了举一反三。体验上，动态情绪和策略化的人格让对话告别枯燥。在 AI 应用爆发的今天，优秀的提示词固然重要，但坚实的底层工程架构才是支撑高阶 Agent 走向生产环境的决定性力量。

在客户端我们可以要求客户在发送之前要把对象放入需要传输的消息前并用@连接，服务器通过获取完整信息得知客户端的需求是发给所有人还是单独发送，这里我们可以规定需要群发就要将发送对象写作-1，若要单独发送就将对应的编号写在发送对象中。通过客户端的发送格式设置和服务器的识别进行广播或者私发，完成基础的通讯功能，后序还可以在此基础加入消息的加密，客户端的登录注册等功能来进一步完善。在实现聊天中会遇见一个常见

通过引入接口，我们成功建立了一套简单的通讯协议，解决了登录与注册区分问题。通过编写页面使得程序从枯燥的控制台输入进化到了图形化交互。

allowedOriginPatterns是则是限制你的访问来源也就是协议+域名+端口号，这里的*是允许所有来源，而在早期的版本中是使用.allowedOrigins("https://your-domain.com")和.allowCredentials(true)来表明这个来源可以访问，早期版本设置.allowCredentials(true)就不能使用*来让所有来源通过了，而现在则是作为一个

所以我们要用一把锁把这些语句给锁着形成一种类似原子操作的结构，我们可以利用synchronized (对象名){}，这里的对象要填一个统一的对象，这样才能保证按顺序执行被锁住的内容。按理来说我们执行完成u1时，在执行u2时会显示用户拥有70，这里是执行权发生了变化，u1执行第一个输出后执行u2的输出，在执行u1的判断和u2的判断，最后输出。在一个大型项目中通常会有着上千上万个线程，线程与线程之间发

在程序运行中，多线程运行时直接使用会涉及线程的频繁启用和销毁，这样会很占用资源，比如在通讯软件中，你和多个人聊天时，同时开启多个线程，过了一会不聊了假如这时关闭线程，那我过不久就又要聊天又开启线程，这样的频繁开启和销毁线程会很占用资源。正在处理的线程会一直存在直至处理完成，如果放入的任务多于线程池处理的线程数量，就会存放至线程池的阻塞队列中，处理完一个线程就从队列中按顺序拿出任务继续处理，临时处理

一般来说类的对象都是在程序运行之前就创建完成的，但是这样会很耗内存，比如在一些3A游戏中，它的环境渲染可以看作是一个对象，如果这些都是在启动阶段创建完成对电脑的要求就会非常高，所以它们采用的是实时渲染，同样的为了解决想在程序运行中可以实时创建对象，我们就要使用反射，那什么是反射。在了解反射之前我们先来了解Class类，Class类不是关键词class，Class类是所有抽象类的类，也就是说所有的类

首先我们先明确mp3有那些结构，MP3分为播放界面和播放列表界面，播放界面由暂停，上一首，下一首的按键，进度条和背景组成。播放列表界面由音乐的列表，上传和存入列表的按钮组成。重写它的构造方法，获取想要的内容，通过获取按钮文本，识别想要的功能。现在我们就还差暂停的实现和上下首的选择。

那我们为了解决这个问题，就想出当我们要用时，在创建对象，加上判断就可以知道当前对象是否为空，但是如果只是加上if来判断会出现多线程并发时，都检测到对象为空，所以以及会创建出两个对象，所以我们要加上锁，但是如果是每次调用方法都要加锁也会太过占用内存，所以我们可以先通过if来筛选第一遍，判断是否加锁，然后再进行判断是否已经创建完成。单例模式是为了解决一个类只用创建一个对象的情况，比如在飞机大战中，玩家