20250409 今天学习单链表反转算法，完成智能协同云图库空间模块前端代码编写

20250408 学习了智能协同云图库图库分析部分代码，复习ConcurrentHashMap ConcurrentHashMap是一个常用的高并发容器类，基础容器HashMap在多线程环境下进行put操作时可能引起死循环，导致cpu飙升甚至达到100%，于是jdk提供了HashTable，HashTable虽然是线程安全的，他的实现原理与HashMap几乎一样，区别在于 ①HashTable不允许key和value为null ②HashTable使用synchronized来保证线程安全，包含get/put在内的所有需要同步执行的方法，是对整个Hash表的锁定，当一个线程在调用put方法写入元素时，其他线程不能调用put添加元素也不能调用get获取元素，相当于所有操作是串行化，所以效率低下。 由此引出了ConcurrentHashMap Jdk1.7版本的ConcurrentHashMap采用Long Addr一样的热点分散原理，内部使用Segment 数组分段锁，一个ConcurrentHashMap包含一个Segment数组，每个Segment包含一个HashEntry数组，每个元素是一个链式结构。 Segment继承ReentrantLock.默认16个Segment对象 Jdk1.8版本的ConcurrentHashMap采用数组+链表或者红黑树的方式，利用CAS+synchronized保证并发

20250407 八股文：学习了CopyOnWriteArrayList的原理和使用， 算法：移除链表特定元素算法一题 项目：智能协同云图库图库分析第一部分

20250406 完成智能协同云图库AI编辑图片，AI扩图部分视频学习

20250405 今天完成了智能协同云图库的后端代码编写，在威联通上搭建好halo博客平台

20250402 今天学习了智能云图库的AI编辑图片功能，前端框架实现，还未编写代码

20250401 今天学习了智能协同云图库图片扩展内容，视频看完了，代码落后了比较多，代码还停留在图片优化章节。要抽时间追上视频进度了

day 004 今天使用了策略模式，学习nginx中proxy_pass用法

day 003今天又遇到了新的问题。 最近几天数据同步批次resttemplate忽然报了413 Request Entity Too Large。排查代码是全量同步7张配置表的数据，一开始以为是最近数据量激增导致的，改了方案分次调用，第一次同步4张，第二次同步3张，等待上线投产后验证。 下午这个批次没跑但其他接口又出现了这个报错，想起最近改了服务调用的机房，本着先恢复应用的前提，还原了之前的请求调用链，问题解决。 后面排查确实是新配置的机房nginx配置不一样，没有配置client_max_body_size，没配置的话这个值默认是1m，当请求报文超过这个值就会报上面错误，而我的报文数确实很大，肯定超过了1m。再看另一机房nginx配置了client_max_body_size为100m，所以还原后请求正常。 以此警示： ①不要因为解决问题随意切换调用链 ②生产上不同机房配置要保持一致，做到真双活 ③同步数据不能粗暴的不带条件删除不带条件插入，保证每时每刻可用需要做增量同步，当然也要考虑业务必要性 ④需要有寻根问底的精神，同事告知我他排查过不是nginx配置引起的，我一开始也看了觉得不是这个原因。后面看部署架构图，调用链如下A-N-N-B,经过两层Nginx，第二层有一个机房NGINX未配置client_max_body_size ⑤重启（还原）是解决大部分问题的首选方法 感悟：生活和工作中不要害怕问题，解决问题是提升最快的方式，

day 002 今天工作中遇到一个很奇怪的问题，顺便复习了线程池的使用，async注解的使用。问题如下 使用ExecutorService的execute方法启动异步任务，异步任务为查询数据循环调用第三方接口，从日志看查到两条记录，需要调用两次，且for循环里记录满足调用条件，不会被过滤，但就是没有输出第二次调用的日志，这个问题出现两次，是在上周上线新功能后出现（未改动到此部分逻辑） 上版本加了一个全局配置类WebMvcConfigure指定了AsyncSupportConfigurer使用自定义线程池，本地没法复现那个问题，目前是先给出问题方法加上日志。如果还有问题就把新加的配置去除