1.keep-alive的码下vue2和vue3的源码以及LRU算法
2.golang面试题库？
3.keepalive部署虚拟IP项目
4.线程池也会导致OOM的原因

keep-alive的vue2和vue3的源码以及LRU算法

       0.LRU算法

       LRU（leastrecentlyused）根据数据的历史记录来淘汰数据，重点在于保护最近被访问/使用过的码下数据，淘汰现阶段最久未被访问的码下数据

       LRU的主体思想在于：如果数据最近被访问过,那么将来被访问的几率也更高

       经典的LRU实现一般采用双向链表+Hash表。借助Hash表来通过key快速映射到对应的码下链表节点，然后进行插入和删除操作。码下这样既解决了hash表无固定顺序的码下考勤统计软件+源码缺点，又解决了链表查找慢的码下缺点。

       但实际上在js中无需这样实现，码下可以参考文章第三部分。码下先看vue的码下keep-alive实现。

1.keep-alive

       keep-alive是码下vue中的内置组件，使用KeepAlive后，码下被包裹的码下组件在经过第一次渲染后的vnode会被缓存起来，然后再下一次再次渲染该组件的码下时候，直接从缓存中拿到对应的码下vnode进行渲染，并不需要再走一次组件初始化，render和patch等一系列流程，减少了script的执行时间，性能更好。

       使用原则：当我们在某些场景下不需要让页面重新加载时我们可以使用keepalive

       当我们从首页–>列表页–>商详页–>再返回，这时候列表页应该是需要keep-alive

       从首页–>列表页–>商详页–>返回到列表页(需要缓存)–>返回到首页(需要缓存)–>再次进入列表页(不需要缓存)，这时候可以按需来控制页面的keep-alive

       在路由中设置keepAlive属性判断是否需要缓存。

2.vue2的实现

       实现原理：通过keep-alive组件插槽，获取第一个子节点。根据include、exclude判断是否需要缓存，通过组件的key，判断是否命中缓存。利用LRU算法，更新缓存以及对应的keys数组。根据max控制缓存的最大组件数量。

       先看vue2的实现：

exportdefault{ name:'keep-alive',abstract:true,props:{ include:patternTypes,exclude:patternTypes,max:[String,Number]},created(){ this.cache=Object.create(null)this.keys=[]},destroyed(){ for(constkeyinthis.cache){ pruneCacheEntry(this.cache,key,this.keys)}},mounted(){ this.$watch('include',val=>{ pruneCache(this,name=>matches(val,name))})this.$watch('exclude',val=>{ pruneCache(this,name=>!matches(val,name))})},render(){ constslot=this.$slots.defaultconstvnode:VNode=getFirstComponentChild(slot)constcomponentOptions:?VNodeComponentOptions=vnode&&vnode.componentOptionsif(componentOptions){ //checkpatternconstname:?string=getComponentName(componentOptions)const{ include,exclude}=thisif(//notincluded(include&&(!name||!matches(include,name)))||//excluded(exclude&&name&&matches(exclude,name))){ returnvnode}const{ cache,keys}=thisconstkey:?string=vnode.key==null?componentOptions.Ctor.cid+(componentOptions.tag?`::${ componentOptions.tag}`:''):vnode.keyif(cache[key]){ vnode.componentInstance=cache[key].componentInstance//makecurrentkeyfreshestremove(keys,key)keys.push(key)}else{ cache[key]=vnodekeys.push(key)//pruneoldestentryif(this.max&&keys.length>parseInt(this.max)){ pruneCacheEntry(cache,keys[0],keys,this._vnode)}}vnode.data.keepAlive=true}returnvnode||(slot&&slot[0])}}

       可以看到<keep-alive>组件的实现也是一个对象，注意它有一个属性abstract为true，是一个抽象组件，它在组件实例建立父子关系的时候会被忽略，发生在initLifecycle的过程中：

//忽略抽象组件letparent=options.parentif(parent&&!options.abstract){ while(parent.$options.abstract&&parent.$parent){ parent=parent.$parent}parent.$children.push(vm)}vm.$parent=parent

       然后在?created?钩子里定义了?this.cache?和?this.keys，用来缓存已经创建过的?vnode。

       <keep-alive>直接实现了render函数，执行<keep-alive>组件渲染的时候，就会执行到这个render函数，接下来我们分析一下它的实现。

       首先通过插槽获取第一个子元素的vnode：

constslot=this.$slots.defaultconstvnode:VNode=getFirstComponentChild(slot)

       <keep-alive>只处理第一个子元素，所以一般和它搭配使用的完整的系统源码有component动态组件或者是router-view。

       然后又判断了当前组件的名称和include、exclude（白名单、黑名单）的关系：

//checkpatternconstname:?string=getComponentName(componentOptions)const{ include,exclude}=thisif(//notincluded(include&&(!name||!matches(include,name)))||//excluded(exclude&&name&&matches(exclude,name))){ returnvnode}functionmatches(pattern:string|RegExp|Array<string>,name:string):boolean{ if(Array.isArray(pattern)){ returnpattern.indexOf(name)>-1}elseif(typeofpattern==='string'){ returnpattern.split(',').indexOf(name)>-1}elseif(isRegExp(pattern)){ returnpattern.test(name)}returnfalse}

       组件名如果不满足条件，那么就直接返回这个组件的vnode，否则的话走下一步缓存：

const{ cache,keys}=thisconstkey:?string=vnode.key==null?componentOptions.Ctor.cid+(componentOptions.tag?`::${ componentOptions.tag}`:''):vnode.keyif(cache[key]){ vnode.componentInstance=cache[key].componentInstance//makecurrentkeyfreshestremove(keys,key)keys.push(key)}else{ cache[key]=vnodekeys.push(key)//pruneoldestentryif(this.max&&keys.length>parseInt(this.max)){ pruneCacheEntry(cache,keys[0],keys,this._vnode)}}

       如果命中缓存，则直接从缓存中拿vnode的组件实例，并且重新调整了key的顺序放在了最后一个；否则把vnode设置进缓存，如果配置了max并且缓存的长度超过了this.max，还要从缓存中删除第一个。

       这里的实现有一个问题：判断是否超过最大容量应该放在put操作前。为什么呢？我们设置一个缓存队列，都已经满了你还塞进来？最好先删一个才能塞进来新的。

       继续看删除缓存的实现：

functionpruneCacheEntry(cache:VNodeCache,key:string,keys:Array<string>,current?:VNode){ constcached=cache[key]if(cached&&(!current||cached.tag!==current.tag)){ cached.componentInstance.$destroy()}cache[key]=nullremove(keys,key)}

       除了从缓存中删除外，还要判断如果要删除的缓存的组件tag不是当前渲染组件tag，则执行删除缓存的组件实例的$destroy方法。

       ————————————

       可以发现，vue实现LRU算法是通过Array+Object，数组用来记录缓存顺序，Object用来模仿Map的功能进行vnode的缓存（created钩子里定义的this.cache和this.keys）

2.vue3的实现

       vue3实现思路基本和vue2类似，这里不再赘述。主要看LRU算法的实现。

       vue3通过set+map实现LRU算法：

constcache:Cache=newMap()constkeys:Keys=newSet()

       并且在判断是否超过缓存容量时的实现比较巧妙：

if(max&&keys.size>parseInt(maxasstring,)){ pruneCacheEntry(keys.values().next().value)}

       这里巧妙的利用Set是可迭代对象的特点，通过keys.value()获得包含keys中所有key的可迭代对象，并通过next().value获得第一个元素，然后进行删除。

3.借助vue3的思路实现LRU算法

       Leetcode题目——LRU缓存

varLRUCache=function(capacity){ this.map=newMap();this.capacity=capacity;};LRUCache.prototype.get=function(key){ if(this.map.has(key)){ letvalue=this.map.get(key);//删除后，再set，相当于更新到map最后一位this.map.delete(key);this.map.set(key,value);returnvalue;}return-1;};LRUCache.prototype.put=function(key,value){ //如果已经存在，那就要更新，即先删了再进行后面的setif(this.map.has(key)){ this.map.delete(key);}else{ //如果map中不存在，要先判断是否超过最大容量if(this.map.size===this.capacity){ this.map.delete(this.map.keys().next().value);}}this.map.set(key,value);};

       这里我们直接通过Map来就可以直接实现了。

       而keep-alive的实现因为缓存的内容是vnode，直接操作Map中缓存的位置代价较大，而采用Set/Array来记录缓存的key来模拟缓存顺序。

       参考：

       LRU缓存-keep-alive实现原理

       带你手撸LRU算法

       Vue.js技术揭秘

原文;/post/

golang面试题库？

       go面试题整理（附带部分自己的解答）

       原文：

       如果有解答的不对的，麻烦各位在评论写出来~

       go的调度原理是基于GMP模型，G代表一个goroutine，不限制数量；M=machine，代表一个线程，最大1万，所有G任务还是在M上执行；P=processor代表一个处理器，每一个允许的swapdic系统源码下载M都会绑定一个G，默认与逻辑CPU数量相等（通过runtime.GOMAXPROCS(runtime.NumCPU())设置）。

       go调用过程：

       可以能，也可以不能。

       因为go存在不能使用==判断类型：map、slice，如果struct包含这些类型的字段，则不能比较。

       这两种类型也不能作为map的key。

       类似栈操作，后进先出。

       因为go的return是一个非原子性操作，比如语句returni，实际上分两步进行，即将i值存入栈中作为返回值，然后执行跳转，而defer的执行时机正是跳转前，所以说defer执行时还是有机会操作返回值的。

       select的case的表达式必须是一个channel类型，所有case都会被求值，求值顺序自上而下，从左至右。如果多个case可以完成，则会随机执行一个case，如果有default分支，则执行default分支语句。如果连default都没有，则select语句会一直阻塞，直到至少有一个IO操作可以进行。

       break关键字可跳出select的执行。

       goroutine管理、信息传递。context的意思是上下文，在线程、协程中都有这个概念，它指的是程序单元的一个运行状态、现场、快照，包含。context在多个goroutine中是并发安全的。

       应用场景：

       例子参考：

       waitgroup

       channel

       len：切片的长度，访问时间复杂度为O(1)，go的游戏攻略网站 源码slice底层是对数组的引用。

       cap：切片的容量，扩容是以这个值为标准。默认扩容是2倍，当达到的长度后，按1.倍。

       扩容：每次扩容slice底层都将先分配新的容量的内存空间，再将老的数组拷贝到新的内存空间，因为这个操作不是并发安全的。所以并发进行append操作，读到内存中的老数组可能为同一个，最终导致append的数据丢失。

       共享：slice的底层是对数组的引用，因此如果两个切片引用了同一个数组片段，就会形成共享底层数组。当sliec发生内存的重新分配（如扩容）时，会对共享进行隔断。详细见下面例子：

       make([]Type,len,cap)

       map的底层是hashtable(hmap类型)，对key值进行了hash，并将结果的低八位用于确定key/value存在于哪个bucket（bmap类型）。再将高八位与bucket的tophash进行依次比较，确定是否存在。出现hash冲撞时，会通过bucket的overflow指向另一个bucket，形成一个单向链表。每个bucket存储8个键值对。

       如果要实现map的顺序读取，需要使用一个slice来存储map的key并按照顺序进行排序。

       利用map，如果要求并发安全，就用sync.map

       要注意下set中的delete函数需要使用delete(map)来实现，但是这个并不会释放内存，除非value也是一个子map。当进行多次delete后，可以使用make来重建map。

       使用sync.Map来管理topic，用channel来做队列。

       参考：

       多路归并法:

       preclass="vditor-reset"placeholder=""contenteditable="true"spellcheck="false"pdata-block="0"(1)假设有K路ahref=""数据流/a，流内部是有序的，且流间同为升序或降序；

       /ppdata-block="0"(2)首先读取每个流的第一个数，如果已经EOF，pass；

       /ppdata-block="0"(3)将有效的k(k可能小于K)个数比较，选出最小的片哈网源码那路mink，输出，读取mink的下一个；

       /ppdata-block="0"(4)直到所有K路都EOF。

       /p/pre

       假设文件又1个G，内存只有M，无法将1个G的文件全部读到内存进行排序。

       第一步：

       可以分为段读取，每段读取M的数据并排序好写入硬盘。

       假设写入后的文件为A,B，C...

       第二步:

       将A，B,C...的第一个字符拿出来，对这个字符进行排序，并将结果写入硬盘，同时记录被写入的字符的文件指针P。

       第三步：

       将刚刚排序好的9个字符再加上从指针P读取到的P+1位数据进行排序，并写入硬盘。

       重复二、三步骤。

       go文件读写参考：

       保证排序前两个相等的数其在序列的前后位置顺序和排序后它们两个的前后位置顺序相同的排序叫稳定排序。

       快速排序、希尔排序、堆排序、直接选择排序不是稳定的排序算法。

       基数排序、冒泡排序、直接插入排序、折半插入排序、归并排序是稳定的排序算法。

       参考：

       head只请求页面的首部。多用来判断网页是否被修改和超链接的有效性。

       get请求页面信息，并返回实例的主体。

       参考:

       ：未授权的访问。

       :拒绝访问。

       普通的.ipv4.tcp_keepalive_intvl=//当探测没有确认时，重新发送探测的频度。缺省是秒。

       net.ipv4.tcp_keepalive_probes=9//在认定连接失效之前，发送多少个TCP的keepalive探测包。缺省值是9。这个值乘以tcp_keepalive_intvl之后决定了，一个连接发送了keepalive之后可以有多少时间没有回应

       net.ipv4.tcp_keepalive_time=//当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时。一般设置为分钟

       修改：

       可以

       tcp是面向连接的，upd是无连接状态的。

       udp相比tcp没有建立连接的过程，所以更快，同时也更安全，不容易被攻击。upd没有阻塞控制，因此出现网络阻塞不会使源主机的发送效率降低。upd支持一对多，多对多等，tcp是点对点传输。tcp首部开销字节，udp8字节。

       udp使用场景：视频通话、im聊天等。

       time-wait表示客户端等待服务端返回关闭信息的状态，closed_wait表示服务端得知客户端想要关闭连接，进入半关闭状态并返回一段TCP报文。

       time-wait作用：

       解决办法：

       close_wait:

       被动关闭，通常是由于客户端忘记关闭tcp连接导致。

       根据业务来啊~

       重要指标是cardinality（不重复数量），这个数量/总行数如果过小（趋近于0）代表索引基本没意义，比如sex性别这种。

       另外查询不要使用select*，根据select的条件+where条件做组合索引，尽量实现覆盖索引，避免回表。

       僵尸进程：

       即子进程先于父进程退出后，子进程的PCB需要其父进程释放，但是父进程并没有释放子进程的PCB，这样的子进程就称为僵尸进程，僵尸进程实际上是一个已经死掉的进程。

       孤儿进程：

       一个父进程退出，而它的一个或多个子进程还在运行，那么那些子进程将成为孤儿进程。孤儿进程将被init进程(进程号为1)所收养，并由init进程对它们完成状态收集工作。

       子进程死亡需要父进程来处理，那么意味着正常的进程应该是子进程先于父进程死亡。当父进程先于子进程死亡时，子进程死亡时没父进程处理，这个死亡的子进程就是孤儿进程。

       但孤儿进程与僵尸进程不同的是，由于父进程已经死亡，系统会帮助父进程回收处理孤儿进程。所以孤儿进程实际上是不占用资源的，因为它终究是被系统回收了。不会像僵尸进程那样占用ID,损害运行系统。

       原文链接：

       产生死锁的四个必要条件：

       （1）互斥条件：一个资源每次只能被一个进程使用。

       （2）请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。

       （3）不剥夺条件：进程已获得的资源，在末使用完之前，不能强行剥夺。

       （4）循环等待条件：若干进程之间形成一种头尾相接的循环等待资源关系。

       避免方法：

       端口占用：lsof-i:端口号或者nestat

       cpu、内存占用：top

       发送信号：kill-l列出所有信号，然后用kill[信号变化][进程号]来执行。如kill-。强制杀死进程

       gitlog:查看提交记录

       gitdiff：查看变更记录

       gitmerge：目标分支改变，而源分支保持原样。优点：保留提交历史，保留分支结构。但会有大量的merge记录

       gitrebase：将修改拼接到最新，复杂的记录变得优雅，单个操作变得(revert)很简单；缺点：

       gitrevert:反做指定版本，会新生成一个版本

       gitreset:重置到某个版本，中间版本全部丢失

       etcd、Consul

       pprof

       节省空间（非叶子节点不存储数据，相对btree的优势），减少I/O次数（节省的空间全部存指针地址，让树变的矮胖），范围查找方便（相对hash的优势）。

       explain

       其他的见：

       runtime2.go中关于p的定义：其中runnext指针决定了下一个要运行的g，根据英文的注释大致意思是说：

       所以当设置runtime.GOMAXPROCS(1)时，此时只有一个P，创建的g依次加入P，当最后一个即i==9时，加入的最后一个g将会继承当前主goroutinue的剩余时间片继续执行，所以会先输出9，之后再依次执行P队列中其它的g。

       方法一：

       方法二：

       [上传失败...(image-4ef-)]

       方法1：to_days，返回给的日期从0开始算的天数。

       方法2：data_add。向日期添加指定时间间隔

       [上传失败...(image-bb-)]

       面试问题总结（一）Golang

       使用go语言的好处:go语言的设计是务实的,go在针对并发上进行了优化,并且支持大规模高并发,又由于单一的码格式,相比于其他语言更具有可读性,在垃圾回收上比java和Python更有效,因为他是和程序同时执行的.

       1.进程,线程,协程的区别,协程的优势

       2.讲一下GMP模型(重点)

       3.Go的GC,混合写屏障(重点)

       4.go的Slice和数组的区别,slice的扩容原理(重点)

       5.讲一下channel,实现原理(重点)

       6.讲一下Go的Map的实现原理,是否线程安全,如何实现安全(重点)

       7.new和make的区别

       8.说一下内存逃逸

       9.函数传指针和传值有什么区别

       .goroutine之间的通信方式

       .测试是怎么做的(单元测试,压力测试)

       .堆和栈的区别

golang面试题2之判断字符串中字符是否全都不同

       请实现个算法，确定个字符串的所有字符是否全都不同。这我们要求不允

       许使额外的存储结构。给定个string，请返回个bool值,true代表所有字符全都

       不同，false代表存在相同的字符。保证字符串中的字符为ASCII字符。字符串的

       度于等于。

       这有个重点，第个是ASCII字符，ASCII字符字符共有个，其中个是常

       字符，可以在键盘上输。之后的是键盘上法找到的。

       然后是全部不同，也就是字符串中的字符没有重复的，再次，不准使额外的储存结

       构，且字符串于等于。

       如果允许其他额外储存结构，这个题很好做。如果不允许的话，可以使golang内置

       的式实现。

       通过strings.Count函数判断：

       使的是golang内置法strings.Count,可以来判断在个字符串中包含

       的另外个字符串的数量

       还有不同的方法同样可以实现，你了解吗?

       推荐go相关技术专栏

       gRPC-go源码剖析与实战_带你走进gRPC-go的源码世界-CSDN博客

keepalive部署虚拟IP项目

       在..4.和..4.上部署虚拟IP，通过keepalive实现高可用性。

       在..4.配置（主）：

       1. 安装依赖包（gcc, gcc-c++, kernel-devel, openssl-devel, popt, libnl, libnl-devel）。

       2. 使用源码安装keepalive。

       3. 创建软链接，将keepalive文件链接至系统路径。

       4. 编辑配置文件（/etc/keepalive/keepalive.conf），设置router_id、虚拟路由ID、优先级和虚拟IP地址。

       5. 重启服务。

       在..4.配置（从）：

       1. 安装依赖包。

       2. 使用源码安装keepalive。

       3. 创建软链接。

       4. 编辑配置文件（/etc/keepalive/keepalive.conf），设置为从机，并设置相关参数。

       5. 重启服务。

       Keepalived支持多种服务的高可用性，通过VRRP协议实现自动接管。

       查看部署的虚拟IP使用命令：ip addr。

       默认日志路径为：/var/log/messages。

       在...（nat公网）上部署虚拟IP..4.5：

       安装依赖包、源码安装keepalive、创建软链接、编辑配置文件、重启服务。

       完成配置后，使用命令检查进程和端口，验证虚拟IP部署成功。

线程池也会导致OOM的原因

       线程池的使用与内存管理

       在编程过程中，我们可能会遇到OOM问题，比如“java.lang.OutOfMemoryError: pthread_create (KB stack) failed: Try again”。这个问题通常与线程创建过多相关。然而，人们往往忽视了一点：线程池也可能导致内存溢出。本文将探讨线程池可能导致内存溢出的原因，以及如何解决这一问题。

       一、线程池的基本理解

       要了解线程池，首先需要从其参数入手，了解其基本工作流程：在任务开始执行时，线程池会先检查当前线程池数量是否达到核心线程数，未达到则创建核心线程执行任务；如果超过核心线程数，任务会放入阻塞队列等待，当阻塞队列满且未达到最大线程数时，会创建非核心线程执行任务；若达到最大线程数，则执行饱和策略。

       核心线程不会回收，非核心线程会在使用完毕后根据keepAliveTime和unit进行回收。这一设计使得核心线程一直存活，占用内存资源。如果创建了大量线程池，就会导致内存溢出。

       二、核心线程如何避免释放资源

       为了避免核心线程因执行完毕而释放资源，我们需要让核心线程进入BLOCKED或WAITING状态，从而在有新任务时被唤醒，进入RUNNABLE状态继续执行。这样，核心线程在执行任务间断时不会进入TERMINATED状态，从而避免释放资源。

       三、线程池源码分析

       在ThreadPoolExecutor类中，当使用线程池执行任务时，会调用execute方法。该方法内部使用了AtomicInteger和自旋（spin）操作来管理线程数量，以实现高效的状态控制和线程创建。当线程数量不足核心线程数时，会调用addWorker方法创建核心线程。

       addWorker方法分为上下两部分，上半部分主要用于状态判断和线程数量的增加，下半部分创建Worker对象并启动线程执行任务。Worker对象内部包含任务和执行该任务的线程，线程的创建依赖于传入的线程工厂。

       四、线程池生命周期与资源管理

       线程池的生命周期分为RUNNING、SHUTDOWN、STOP、TIDYING和TERMINATED等状态。shutdown()和shutdownNow()方法可以改变线程池的状态，但对资源管理影响较小。核心线程不会因执行完毕而立即释放资源，非核心线程在使用完毕后根据keepAliveTime和unit进行回收。

       五、结论与思考

       通过部分源码分析，我们了解到线程池可能导致内存溢出的原因，关键在于核心线程的持续占用资源。不断创建线程池不一定导致内存溢出，取决于线程池的大小、核心线程数、keepAliveTime以及任务执行情况。在实际应用中，合理设置线程池参数，以及正确处理任务调度，是避免内存溢出的关键。