gc调优(parnew+cms)

1如何做gc调优#

调优目的:减少系统停顿时间
优化目标:减少younggc、减少cmsgc、减少fullgc
Old GC:只清理老年代空间的 GC 事件,只有 CMS 的并发收集是这个模式。
Full GC:清理整个堆的 GC 事件,包括新生代、老年代、元空间等 。

1.1younggc原因#

1.请求中生成的对象多。新生代空间较小,Eden区很快被填满,就会导致频繁young GC

1.1如何减少younggc#

1.增大新生代空间
2.减少请求中生成对象大小
1.2cmsgc原因
1.有过多的对象到达了老年代,频繁触发cms gc
1.2如何减少cmsgc
1.增大老年代大小
2.减少进入老年代的对象大小, 提高晋升年龄阈值(如果小的话,比如改成了3、4)

1.3fullgc原因#

1.metaspace扩容

2.CMS GC时出现promotion failed(晋升失败)和concurrent mode failure 触发串行full gc。

promotion failed: 当新生代发生垃圾回收,老年代有足够的空间可以容纳晋升的对象,但是由于空闲空间的碎片化,导致晋升失败,此时会触发单线程且带压缩动作的Full GC
concurrent mode failure: 发生的原因一般是CMS正在进行,但是由于老年代空间不足,需要尽快回收老年代里面的不再被使用的对象,这时停止所有的线程,同时终止CMS,直接进行Serial Old GC

3.统计得到的Young GC晋升到老年代的平均大小大于老年代的剩余空间;

4.主动触发Full GC,

程序代码执行System.gc(); 
命令行中dump整个堆: 执行jmap -histo:live [pid]

1.3如何减少fullgc#

原因1. 启动时设置好metaspace,避免因扩容导致fullgc
“-XX:MetaspaceSize=256M”,
“-XX:MaxMetaspaceSize=256M”

原因2&3. 减少cms gc

•降低触发CMS GC的阈值, 以保证有足够的空间。即参数-XX:CMSInitiatingOccupancyFraction的值,让CMS GC尽早执行。
•增大老年代空间
•让对象尽量在新生代回收,避免进入老年代

原因4. 避免使用System.gc()

2.Jvm如何内存分配#

eg: 16G内存机器,9G老年代,4G新生代,3G直接内存

3.gc调优案例#

3.1younggc#

1.请求中生成的对象大,eg:历史数据因历史原因对应很多或很大的返回结果,频繁访问造成gc较多,可以在场景允许的情况下将这部分数据下掉或者做个截断处理。减少younggc的频率和复制对象所花费的时间。
2.增大新生代大小

3.2fullgc#

1.服务启动时metaspace扩容触发fullgc,导致刚启动时服务不稳定,jvm启动参数中设置好Metaspace的size和最大size。
2.服务偶尔发生concurrent mode failure。服务瞬间的可用性下降严重。修改jvm参数,降低触发cms gc的阈值(90%->75%),避免触发串行full gc。

3.3cmsgc#

1.增大old区。肯定是有用的,至少能减少触发的频率
2.也可能是晋升年龄阈值比较小。-XX:MaxTenuringThreshold,默认15, 可能有人改小了,让年龄小的就直接到old区了,比如改成3、4。

备注:cms内存碎片问题#

通常 CMS 的 GC 过程基于标记清除算法,不带压缩动作,导致越来越多的内存碎片需要压缩。常见以下场景会触发内存碎片压缩
新生代 Young GC 出现新生代晋升担保失败(promotion failed))

程序主动执行System.gc()

可通过参数 CMSFullGCsBeforeCompaction 的值,设置多少次 Full GC 触发一次压缩。默认值为 0,代表每次进入 Full GC 都会触发压缩,带压缩动作的算法为上面提到的单线程 Serial Old 算法,暂停时间(STW)时间非常长,需要尽可能减少压缩时间。

innodb事务隔离级别

一、定义#

未提交读(Read Uncommitted):允许脏读,也就是可能读取到其他会话中未提交事务修改的数据
提交读(Read Committed):只能读取到已经提交的数据. 可以阻止脏读,但是可能发生幻读或不可重复读
可重复读(Repeated Read):可重复读。在同一个事务内的查询都是事务开始时刻一致的. 可以阻止脏读和不可重复读,幻读通过mvcc解决了快照读,next-key锁解决了当前读. mysql默认隔离级别.
串行读(Serializable):读加共享锁,写加排他锁,读写互斥.

可重复读指的是同一行在同一个事务下无论怎么读取都是同一个结果(除非自己把它改了).

幻读指的是在同一事务下,连续执行两次同样的SQL语句第二次的SQL语句可能返回之前不存在的行;

二、什么是快照读,什么是当前读#

快照读:就是select

1
select * from table ….;

当前读:特殊的读操作,插入/更新/删除操作,属于当前读,处理的都是当前的数据,需要加锁。

1
2
3
4
5
select * from table where ? lock in share mode;
select * from table where ? for update;
insert;
update ;
delete;

事务的隔离级别实际上都是定义了当前读的级别,MySQL为了减少锁处理(包括等待其它锁)的时间,提升并发能力,引入了快照读的概念,使得select不用加锁。而update、insert这些“当前读”,就需要另外的模块来解决了

三、rr级别下mvcc解决不可重复读和快照读之间的幻读#

一致非锁定读,也可以称为快照读,即普通SELECT语句,既然是快照读,故 SELECT 的时候,会生成一个快照。

生成快照的时机:事务中第一次调用SELECT语句的时候才会生成快照,在此之前事务中执行的update、insert、delete操作都不会生成快照

REPEATED READ 隔离级别下,快照会在事务中第一次SELECT语句执行时生成,只有在本事务中对数据进行更改才会更新快照,因此,只有第一次SELECT之前其它已提交事务所作的更改你可以看到,但是如果已执行了SELECT,那么其它事务commit数据,你SELECT是看不到的。

四、rr级别下next-key锁解决当前读之间的幻读#

在当前读下rr级别使用了next-key锁(临键锁),临键锁包括行锁+间隙锁, 来避免两个当前读时有其它事务插入数据,所以当前读使用next-key锁解决的幻读。

最后备注下:如果是先快照读再当前读,影响行数不一致是否属于幻读,是有争议的但大多认为并不是幻读。

五、rr和rc区别#

rc级别下的mvcc总是读取数据行的最新快照,而rr级别下的mvcc,会在事务第一次select的时候,为数据行生成一个快照,后面每次都读这个快照,除非自己更新

如果问,rr为什么是默认的隔离级别,就说rr相比rc来说没有不可重复读和幻读问题. 后面再深入研究

六、todo学习#

  1. rr为什么是默认的隔离级别
  2. mvcc在rc隔离级别下,读最新的快照,为什么不直接读行记录呢,rc级别是怎么解决脏读的

参考文章#

https://tech.meituan.com/2014/08/20/innodb-lock.html

快手面经

时间:2020.01 经验 2.5

一面:

自我介绍

springaop的理解、动态代理

concurrenthashmap的线程安全

AQS的原理,怎么保证线程安全

CAS的原理

mysql的事务隔离级别

volatile的原理、内存屏障使用

怎么创建索引

gc算法、垃圾收集器、常用,怎么解决gc问题

算法:无放回等概率的随机抽取,1-1亿,int数组即可

二面:

自我介绍

每个项目介绍、难点、扩展点,比如本地缓存实现原理、未来容量增加、库存秒杀写并发量很大,分库存核销不均解决等

设计一个问卷系统、弹出问卷中包含题目,选项等,设计数据库表、缓存、接口

算法:输入n用二维数组内1的形状为等腰三角形

你觉得研发最重要的是什么。答:代码质量和线上质量两部分

三面(leader):

为什么想换工作

新工作考虑哪些因素

介绍一个项目中的设计或架构

项目中这样设计有哪些优点缺点

工作中怎么判断需求的好坏。答:从需求价值、产品水平、产品以往经历

怎么在开发迭代中做项目优化的闭环。答:判断需求是否属于自身领域,逻辑是否合理,实现是否满足,实现是否很难,很难的原因是什么,是代码逻辑有问题还是架构设计不合理

四面(hr):

为什么想换工作

你的老板对你的评价是怎么样的

你自己觉得优缺点是什么样的

你在工作中有遇到什么困难吗,怎么解决的

幂等设计

请求幂等性总结:

1.是否需要幂等。比如查询,insert含唯一索引的表,update set数据,delete by id 等简单场景是天然幂等。不需要额外做幂等操作。无法这样的比如要做数据的累加,就要做幂等。

2.如何判断重复。

业务唯一键,查记录表或流水表,根据记录的有无和状态来判断。

3.实现。

  1. 简单的话接口直接实现, 但通常幂等逻辑是有通用性的
  2. 如果服务多接口使用写幂等工具类
  3. 如果多服务使用一套幂等逻辑,写sdk
  4. 最复杂的多服务间幂等,还无法都获取到记录结果,就要在sdk统一读写幂等表,读写相同的幂等记录做幂等

4.并发处理

  1. 单机情况下,使用java锁synchronized
  2. 使用数据库锁,悲观锁:select for update,乐观锁:update set XXX and version = 2 where version = 1
  3. 使用分布式锁:
    redis锁:1.过期时间导致并发问题,2.主从切换时锁丢失
    zookeeper锁:写能力不如redis

原文:

  1. 维度1 : 是否需要幂等处理?

    1. 查询场景

      select 字段 from 表 where 条件 ,这种是不会对数据产生任何变化,所以查询场景具备天然幂等性;注意这里的幂等是对系统资源的改变,而不是返回数据的结果,即使返回结果不相同但是该操作本身没有副作用,所以幂等

    2. 新增场景

      insert into 表 (order_id,字段) value(1,字段) :

      1)如果order_id为唯一键,重复操作上面的业务,只会插入一条数据,具备天然幂等性。

      2)如order_id不是唯一键,那上面业务多次操作,数据都会新增多条,不具备幂等性。

    3. 修改场景

      1)直接赋值场景:update 表 set price = 20 where id=1 ;分析: 这种场景不管执行多少次,price都一样,具备天然幂等性;

      2)计算赋值场景:update 表 set price = price + 20 where id=1,每次操作price数据都不一样,不具备幂等性;

    4. 删除场景

      1)delete from 表 where id=1 ,多次操作,结果一样,具备天然幂等性

      2)delete from 表 where price > 20,多次操作,结果一样,具备天然幂等性

      总结:单纯的查询接口,删除接口,没有计算的更新接口,每次执行结果是天然幂等的,其他情况则可能需要做幂等

  2. 维度2 : 是否需要并发控制?

    1. 场景1: 唯一键数据的重复插入

      此场景不需要并发控制,天然并发安全,但需要业务方处理DuplicateKeyException异常

    2. 场景2:转账,若 a >= 100, a -100, b+100

      此场景为了保证数据一致性,事务原子性,需要顺序执行

      总结:除了极其简单的场景外,大部分幂等场景都需要并发控制,需要强锁还是弱锁

  3. 维度3 : 如何判断是重复请求?

    1. 场景1: 无业务主键的新增

      此场景下需要服务端颁发token,通过token判断是否重复,做防重复提交

    2. 场景2: 有业务唯一键的新增

      此场景下可以使用业务唯一键判断是否重复

    3. 场景3: 有业务唯一键的更新

      此场景下可以使用业务数据对应的状态判断是否重复

  4. 维度4 : 重复请求处理方式?

    1. 场景1:消息重复消费

      此场景下,不需要给上游一个返回,重复执行只需要丢弃

    2. 场景2:前端重复提交

      此场景下,需要给用户一个提示,那么重复请求可以直接抛出一个DuplicateReqeustException异常,由上层捕获,前端展示“请不要重复请求”

    3. 场景3: 底层的转账接口

      此场景下,同一笔转账,重复调用第一次若成功了,第二次应该返回相同“成功”,若第一次失败了,第二次返回业务执行结果

      结论:根据不同场景,应该有不同的结束方式,应该由业务方自己决定是丢弃,抛异常,直接返回,还是执行业务逻辑

  5. 维度5 : 重复请求返回是否相同?

    1. 场景1:第一次执行成功,第二次返回应该与第一次相同

    2. 场景2:第一次执行因为代码原因导致的异常而失败,第二次返回应该与第一次相同

    3. 场景3:第一次执行因为网络原因失败,第二次应该执行业务逻辑,返回结果可能不一致

      总结:根据第一次执行的成功和失败,判断第二次应该执行业务逻辑还是直接返回相同结果

  6. 维度6 : 重复请求调用下游如何处理?

    1. 场景1: 业务逻辑中,有调用下游rpc接口,第一次执行失败,第二次重复执行业务逻辑再次调用下游接口

      总结:此场景本质上是一个分布式一致性问题,需要业务方自己解决,或者保证下游接口也是幂等的

  7. 识别相同请求

    1. token机制:每次提交上来的请求,都带上一个token标识,同一个token只处理一次,例如:新增场景的防止重复提交
    2. 业务唯一标识:使用id或者unique key,例如:支付后,支付凭证落库
    3. 业务唯一标识 + 状态:支付后,通过支付凭证号和当前订单状态,更新订单状态
    4. 在业务侧建立同库幂等数据表,记录请求唯一键和执行状态,执行成功后更新状态为成功
  8. 并发处理方式

    1. 单机情况下,使用java锁synchronized

    2. 使用数据库锁,悲观锁:select for update,乐观锁:update set XXX and version = 2 where version = 1

    3. 使用分布式锁:

      redis锁:1.过期时间导致并发问题,2.主从切换时锁丢失

      zookeeper锁:写能力不如redis

  9. 一致性保证

    1. 业务方需保证原子性,本地更新都在一个事务里
    2. 若无法保证分布式事务,下游接口需是幂等的,且本地事务必须重试达到最终一致

SDK设计#

  1. 并发控制
    1. 提供注解,按业务自动划分,提供指定幂等唯一键
    2. 提供并发控制,分布式锁服务(redis或zk),指定分布式锁时间
    3. 提供并发时幂等处理方式,丢弃/抛异常/等待锁
    4. 提供降级选择,不强依赖于锁服务
    5. 提供token注解,防止重复提交
  2. 判断重复请求

处理方式 优点 缺点

方案一 业务方自己判断 业务方需要自己考虑判重

方案二 sdk提供判重接口,由业务方实现 可以实现重复请求的通用处理

方案三 幂等表:在业务侧建立同库幂等数据表,记录请求唯一键和执行状态,执行成功后更新状态为成功 业务方无需再关心判重问题 数据量大,开发量大,复杂度较高

缓存穿透、击穿、雪崩

缓存穿透#

定义: 访问一个不存在的key,缓存不起作用,请求会穿透到DB,流量大时DB会挂掉。

解决方案:

  1. 缓存空值 (值少时)
  2. 布隆过滤器, 特性: 没有的肯定没有,有的不一定有

缓存击穿#

定义:并发性,一个存在的key,在缓存过期的一刻,同时有大量的并发请求,这些请求都会击穿到DB,造成瞬时DB请求量大、压力骤增。

解决方案:

  1. 分布式锁,在访问key之前,采用分布式锁SETNX(set if not exists)来设置另一个短期key来锁住当前key的访问,访问结束再删除该短期key

缓存雪崩#

定义:大量的key设置了相同的过期时间,或者某台服务器宕机,导致大量缓存在同一时刻全部失效,造成瞬时DB请求量大、压力骤增,引起雪崩。

解决方案:

  1. 将key的过期时间设置时添加一个随机时间,分散过期时间
  2. 如果是热点key,可以加分布式锁,减少并发量
  3. 二级缓存(本地缓存),减少db压力

2019国庆上海苏州四日游记

9月30日 外滩 很久以前羊肉串#

接到小菜猫,先去旅馆放下东西,直接去外滩。 南京东路上都是武警,维持秩序,看着有点厉害。我是第二次来外滩,小菜猫是第一次,还是很好看的,人很多,当晚有灯光表演,30分钟一次,我们赶上了一半。海风很舒服。整个外滩的爱国氛围也很浓厚。

外滩

去吃了很久以前羊肉串,吃到晚上12点多,羊肉真的好嫩,当面烤也是特色,配上啤酒,舒服,长肉。

10月01日 武康路#

武康路没有拍什么照片,是一条安静古老的小路,下着小雨,氛围很好

在这里出发去世界上最大的星巴克

一栋星巴克,里面两层。点了一杯奶和一杯咖啡。没有太好喝但环境很好,主要咖啡☕️咱也不懂。里面有些机器在做咖啡,全流程透明化。

下午5点多了,风雨越来越大,继续出发,去豫园&城隍庙,但到了之后风雨太大,也没找到豫园在哪,哈哈,就转地铁回去了。

晚上去吃了和府捞面,办了会员,赠了个虾,嚯,真虾(瞎)

10月2日 蟹面 诚品书店 金鸡湖#

上午出门去吃蟹面,尴尬的是行李太沉,不该带着行李去吃,不过蟹面还是很不错,从没吃过这样式儿的,带汤的那碗很不错,人超级多,排了好一会儿

出发去苏州~

上海到苏州也太快了,半个小时就到了,小菜猫睡了一会儿,我还没睡就到了,放下行李先奔了金鸡湖

诚品书店太安静了,没怎么拍照片,金鸡湖还是很美的,毕竟北方湖还是很少的。见到漂亮的湖,小风一吹,还是很爽。

美美哒

晚上吃了高级台湾自助火锅,到了才发现是自助,不过还是靠实力吃回来了。

10月3日 怡园 留园#

上午要去留园,然后我拉肚子,耽误了坐车,就先去了怡园,没想到怡园还不错,后来发现留园反而因为人多,毫无观赏体验。

怡园

留园就不放了,人太多了,下次不去那么多人的地方了。。

10月4日 归途#

沿途的风光也不错,回家啦

2019国庆上海苏州四日游行程计划

2019 国庆上海苏州四天旅行#

行程规划#

北京前往上海 9.30 14:10 - 20:09 G141 检票口 11

9月30日#

住宿 上海家荣酒店公寓(中山公园店)
21点 很久以前羊肉串(中山公园店)

10月1日#

上午 9点
武康路
上午 11点
田子坊
下午1点
豫园&城隍庙 ,明朝时期的私人花园,拥有“城市山林”、“奇秀甲于东南”两种美称,是江南园林中的一颗明珠。
下午4点
东方明珠
南京路步行街
下午7点半
外滩 外滩观光隧道

10月2日#

上午9点
中华艺术宫
上午12点
退房
下午14:41 上海前往苏州 14:41 - 15:15 D3010 检票口 25A
住宿 骏怡连锁酒店
下午4点半
诚品书店
金鸡湖
阳澄湖大闸蟹

10月3日#

上午9点
拙政园
苏州博物馆
下午1点
虎丘
留园
网师园夜景

10月4日#

苏州前往北京 10.4 11:40 - 17:10 G128 检票口 A1

springioc初始化

IOC 容器的初始化过程分为三步骤:Resource 定位、BeanDefinition 的载入和解析,BeanDefinition 注册

1.Resource 定位。我们一般用外部资源来描述 Bean 对象,所以在初始化 IOC 容器的第一步就是需要定位这个外部资源。

2.BeanDefinition 的载入和解析。装载就是 BeanDefinition 的载入。BeanDefinitionReader 读取、解析 Resource 资源,也就是将用户定义的 Bean 表示成 IOC 容器的内部数据结构:BeanDefinition。在 IOC 容器内部维护着一个 BeanDefinition Map 的数据结构,在配置文件中每一个都对应着一个BeanDefinition对象。

3.BeanDefinition 注册。向IOC容器注册在第二步解析好的 BeanDefinition,这个过程是通过 BeanDefinitionRegistery 接口来实现的。在 IOC 容器内部其实是将第二个过程解析得到的 BeanDefinition 注入到一个 HashMap 容器中,IOC 容器就是通过这个 HashMap 来维护这些 BeanDefinition 的。在这里需要注意的一点是这个过程并没有完成依赖注入,依赖注册是发生在应用第一次调用 getBean() 向容器索要 Bean 时。当然我们可以通过设置预处理,即对某个 Bean 设置 lazyinit 属性,那么这个 Bean 的依赖注入就会在容器初始化的时候完成。

记录租房第三个住处-天通苑东三区

上上周末8月24号搬到了新的租房,搬到了天通苑北一区,换了一居,也住了十几天了,感觉很不错,但之前的租房也很好,它有一个大大的天台,还可以上房顶,把照片记录下来。

上周末回去稍微收拾了下屋子,卖了东西,图中为美丽聪慧的对象

客厅兼卧室

很大的地方还有个落地灯

厨房以前在这个地方,这个屋在之前一段时间我们都把垫子搬过来打地铺睡,因为有一天我发现这里比较隔猫

我的电脑桌放在这个地方

大大的厕所,目前住过最大厕所

小储藏室

通往天台的门,lily最爱去的地方,总是会在这个地方站好开叫,然后看你过来了就扒扒门,lily非常渴望自由,想出去玩

出来啦!

有一圈的天台,第一次见时真的很惊喜

视野十分开阔,夕阳西下,喝酒吃肉,美滋滋

在小区里捡到了很能叫又贪吃的新家庭成员,小 jojo

开始小小的很可爱,

陪我玩电脑

写博客

要抱抱

举高高

与lily从打闹慢慢有点和谐相处

学lily睡窗台

和我们一起睡觉,四生物一张床

后来因为早上太闹,用梳妆台挡住这两个捣蛋鬼,jojo此时已显猪态

幸福生活未完待续..

rss订阅

使用 feedly 订阅 rss,实现多设备同步

教程:https://techmoon.xyz/feedly/

目前导出的我的订阅源, Feedly订阅.opml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
<?xml version="1.0" encoding="UTF-8"?>
<opml version="2.0">
<head>
<title>Feedly订阅</title>
</head>
<body>
<outline title="NBA" text="NBA">
<outline text="千年孤寂 的 Youtube 视频" title="千年孤寂 的 Youtube 视频" xmlUrl="https://rsshub.app/youtube/channel/UC6QUkl7S6AYwkpQFhmdFIoQ" type="rss" htmlUrl="https://www.youtube.com/channel/UC6QUkl7S6AYwkpQFhmdFIoQ" />
<outline htmlUrl="https://space.bilibili.com/184687394/#/article" title="听说不怕肚子疼 的 bilibili 专栏" type="rss" text="听说不怕肚子疼 的 bilibili 专栏" xmlUrl="https://rsshub.app/bilibili/user/article/184687394" />
</outline>
<outline text="产品" title="产品">
<outline title="李自然说 的 bilibili 空间" xmlUrl="https://rsshub.app/bilibili/user/video/39089748" type="rss" htmlUrl="https://space.bilibili.com/39089748" text="李自然说 的 bilibili 空间" />
<outline htmlUrl="https://post.smzdm.com/hot_7" type="rss" xmlUrl="https://rsshub.app/smzdm/haowen/7" text="周热门-什么值得买好文" title="周热门-什么值得买好文" />
<outline xmlUrl="http://fz0512.com/feed" text="最好金龟换酒" title="最好金龟换酒" htmlUrl="http://fz0512.com" type="rss" />
<outline title="少数派" text="少数派" htmlUrl="https://sspai.com" xmlUrl="http://sspai.com/feed" type="rss" />
<outline text="V2EX-最热主题" xmlUrl="https://rsshub.app/v2ex/topics/hot" title="V2EX-最热主题" type="rss" htmlUrl="https://www.v2ex.com/" />
<outline title="微信公众号 - 一本黑" text="微信公众号 - 一本黑" xmlUrl="https://rsshub.app/wechat/csm/darkinsider" type="rss" htmlUrl="https://chuansongme.com/account/darkinsider" />
</outline>
<outline text="图片" title="图片">
<outline title="国家地理每日一图" text="国家地理每日一图" type="rss" htmlUrl="https://www.nationalgeographic.com" xmlUrl="https://feedx.co/rss/nationalgeodayphoto.xml" />
</outline>
<outline title="好友" text="好友">
<outline title="大菜猫" htmlUrl="https://www.techwei.cn/" text="大菜猫" xmlUrl="https://techwei.cn/atom.xml" type="rss" />
<outline htmlUrl="https://jacobchang.cn/" text="黄小豆的博客" title="黄小豆的博客" type="rss" xmlUrl="https://jacobchang.cn/atom.xml" />
<outline xmlUrl="https://rsshub.app/bilibili/user/video/11036610" text="爱浪的黄小豆 的 bilibili 空间" type="rss" title="爱浪的黄小豆 的 bilibili 空间" htmlUrl="https://space.bilibili.com/11036610" />
<outline htmlUrl="https://www.yuanqiongqiong.cn/" title="袁琼琼的博客" xmlUrl="http://yuanqiongqiong.cn/atom.xml" text="袁琼琼的博客" type="rss" />
</outline>
<outline text="技术" title="技术">
<outline xmlUrl="https://rsshub.app/juejin/category/backend" type="rss" text="掘金后端" title="掘金后端" htmlUrl="https://juejin.im/welcome/backend" />
<outline type="rss" text="美团技术团队" htmlUrl="https://tech.meituan.com/feed/" xmlUrl="https://rsshub.app/meituan/tech/home" title="美团技术团队" />
<outline htmlUrl="http://www.ruanyifeng.com/blog/" xmlUrl="http://www.ruanyifeng.com/blog/atom.xml" title="阮一峰的网络日志" type="rss" text="阮一峰的网络日志" />
<outline htmlUrl="https://chuansongme.com/account/importnew" type="rss" xmlUrl="https://rsshub.app/wechat/csm/importnew" text="微信公众号 - ImportNew" title="微信公众号 - ImportNew" />
<outline title="微信公众号 - 一本黑" type="rss" text="微信公众号 - 一本黑" htmlUrl="https://chuansongme.com/account/darkinsider" xmlUrl="https://rsshub.app/wechat/csm/darkinsider" />
</outline>
<outline text="新闻" title="新闻">
<outline xmlUrl="https://rsshub.app/gov/zhengce/zuixin" type="rss" text="最新政策 - 中国政府网" title="最新政策 - 中国政府网" htmlUrl="http://www.gov.cn/zhengce/zuixin.htm" />
</outline>
<outline text="生活" title="生活">
<outline text="美国日记" title="美国日记" type="rss" htmlUrl="http://cn.derekyang.us" xmlUrl="http://cn.derekyang.us/?feed=rss2" />
<outline text="人生不过如此" htmlUrl="http://nana.blog.paowang.net" title="人生不过如此" xmlUrl="http://nana.blog.paowang.net/feed/" type="rss" />
</outline>
<outline title="电影" text="电影">
<outline htmlUrl="https://www.douban.com" type="rss" xmlUrl="https://feedx.co/rss/doubanmvweek.xml" text="豆瓣电影本周口碑榜" title="豆瓣电影本周口碑榜" />
<outline text="MovieTalk-电影七日谈 的 bilibili 空间" title="MovieTalk-电影七日谈 的 bilibili 空间" xmlUrl="https://rsshub.app/bilibili/user/video/10869763" htmlUrl="https://space.bilibili.com/10869763" type="rss" />
</outline>
<outline title="艺术" text="艺术">
<outline type="rss" htmlUrl="http://bing.com" text="必应今日美图" title="必应今日美图" xmlUrl="https://feedx.co/rss/bingwallpaper.xml" />
</outline>
</body>
</opml>
</opml>
Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×