网易实习问题记录

内存泄漏问题（20.09.23）

发生在我第一次上线代码的时候，当时上线代码后，需要观察日志的输出情况
查看了几次日志后发现日志输出正常就没管了
但是在之后线上系统报警告，内存占用过高
通过登录线上系统用top命令查看占用率较高的几个进程，发现有多个vim进程占用大量内存
最后发现是我使用vim命令来观察日志，且没有退出，直接关闭页面，导致的多个vim进程占用内存

以后看日志用less或者tail命令，不要用vim

发布接口后前端无法访问404（20.09.25）

首先应该确定当前部署环境的版本是我们最新的版本号，选中项目->Git->Show History看提交历史
选中最新版本，右键->Copy Revision Number，然后去查看和当前部署的版本号是否一致
最后发现是自己微服务部署错了，部署了另一个微服务

接口返回500，服务器错误（20.09.29）

问题发现：在写好接口后，进行postman测试时发现响应码为500，查看系统日志发现报了空指针异常
解释：在本地进行调试，发现在进入到接口中时，spring中bean自动装配失败，全部为null，导致的空指针
通过上网查发现是由于接口对应方法的权限修饰符为private而没写public导致的自动装配失败

这可能是springboot的bug，因为自动装配的底层原理是利用反射实现的，因此如果接口使用的是private，可能会导致反射的注入失败

分页展示部分记录丢失(20.10.15)

问题发现：导出接口导出的数据有些记录在展示接口中没有查到，发现展示接口有部分记录丢失
解释：mysql在使用limit进行分页展示时，如果order by后的字段会出现重复值，可能会在分页查询时丢失部分临界记录
经验：在使用order by语句的时候后面的字段应该尽可能不重复，如果重复可以加上主键id字段

合代码时发现很多改动都是自己没改的(20.10.20)

问题发现：在提交分支合并的merge请求时，发现很多文件发生了改动，同时这些改动都不是自己改的
		之后通过和master和测试分支进行compare，发现开发分支是从测试分支中新建的，只能重新开发了
经验：每天开发之前检查一下自己开发的分支是从master中新建的，而不是从测试分支中新建的

前后端版本不兼容的问题(20.10.20)

解释：因为一般上线时是先上后端，然后再上前端，这就可能导致新后端和旧版本前端不兼容的问题
        比如出现后端新增的字段前端没传值，导致后端报错的情况
经验：因此在上线之前应该在测试环境确认前后端版本的兼容问题，任何系统都一样

mybatis中使用!=''导致Integer类型无法插入

问题发现：mybatis中写sql使用!=''作为过滤条件时，发现该字段的插入更新都有问题
解释：Integer类型的字段使用!=''不能判断是否满足，所以会当成被过滤掉
经验：Integer类型的字段使用!=null即可，不用使用!=''，String类型的才用使用!=''

内连接导致数据不能展示（20.10.26）

问题发现：上线了一个功能，该功能需要使用实时数据表和离线数据表联表查询，但是上线后发现数据不能实时展示
解释：在联表查询的时候使用了inner join，即内连接，导致只能展示实时表和离线数据表中都有值的记录
	但是离线数据是一天跑一次的，所以导致数据不能实时展示
经验：类似于这种需要实时数据表和离线数据表联查的需求，要考虑是使用inner join还是left join，这个需要看业务需求

高并发导致的更新丢失问题（20.11.10）

问题发现：因为别的系统需要调用push后台这边的接口查询push打开数和打开率的实时数据
		但是发现数据库中的数据在某些时刻会被更新成0
解释：因为汇总数据大数据部门是
		分4次(第一次只有send_num,第二次只有arrive_num,第三次只有show_num,第四次只有open_num)
		写入kafka的，且前后之间只有几微秒
		这就导致在更新的时候会出现前面更新的数据，被后面的更新的语句覆盖的问题
		把不更新的字段置成null，不更新，就不会出现覆盖问题了
经验：在高并发的情况的应该注意数据库的更新和插入覆盖的情况

CMS线上事故(20.11.12)

问题发现：编辑在群里反馈发现上了cms非精编类型后，其余类型的标题变成了“热点资讯”
解释：在更改非精编业务逻辑的时候，没有在非精编自己的方法中进行修改，而是更改了所有类型公用的方法。
	导致其他类型的业务受到了影响
经验：在代码review的时候应该注意，同时在测试环节应该各种类型都测试一遍，防止出现其他影响

Mybatis出现的类型转换错误(20.11.13)

解释：sql中的sum()函数会将字段的类型从int升级成BigDecimal，导致转换成String出现错误

Apollo配置时@apolloconfig和@apolloconfigchangelistener无效(20.11.17)

问题发现：在配置了@apolloconfigchangelistener之后，发现在测试环境更改apollo配置监听器没有反应
		之后配置了@apolloconfig注解后config会报空指针，发现这两个注解都无效
解释：不知道原因
经验：注解虽然无效，但是可以通过congif.addListener()手动添加监听器

迷惑的ThreadLocal(20.12.18)

问题发现：消息中心需要进行查询记录的去重，因此使用了ThreadLocal用于保存上一次查询出的结果，
		但是加上ThreadLocal发现，并没有效果，加上日志后发现ThreadLocal中的内容在去重前发生了变化
解释：在将上一次的查询结果set进ThreadLocal时，我们并没有使用.clone()的方式
	 而是直接将对象set进了ThreadLocal中，因此set的是对象的引用，
		而这个对象会被方法return，然后被其他方法操作，这会导致我们ThreadLocal中的对象也被修改
经验：之后传递引用数据类型时，尽量使用.clone()的方式，避免不必要的麻烦

加日志后执行结果发生变换(20.12.14,Leader)

问题发现：为了定位问题，在推荐系统中加上了很多日志，只上了一台机子进行观察，
		但是发现加了日志的机子发送会比其他机子发送的要少很多
解释：闯哥定位了很久，最后发现是加了日志后发送时间变长了，最终结果导致总体发送变少
经验：不要加太多无用日志，只加关键日志，同时需要考虑到对运行效率的影响

优化器趋向选择主键的问题(20.12.21)

问题发现：消息中心的后台消息展示，因为没有添加时间约束会把一个频道中的所有消息都进行展示
		在数据量达到一定程度后，查询会超时，判定为慢sql
		但是加了包含时间的联合索引后查看执行计划，发现mysql选择的还是原本的主键索引
解释：mysql的优化器会自行选择它认为效率更好的索引，而使用主键索引不需要回表
	在数据量大到一定程度后使用非主键索引然后回表的消耗可能比直接使用主键索引的消耗更大
经验：正常情况下优化器的选择都是对的，但是如果非常确定优化器选择错了
	我们可以使用force index()强制指定索引

问题思考

1.如何建立倒排索引，用标签查设备，查询设备的标签
2.MySQL的存储引擎除了InnoDB和MyISAM外，还有myrocks
	myrocks相比于InnoDB适用于数据量大而内存小的情况，写快但是读慢，能节省大量的硬件资源
	有一定的业务场景能代替Redis
	场景：通道中的写设备的过程就可以使用

工作经验

1.常量用枚举！！不要在代码中写常量
2.多看看工具类，看看别人写的接口能加快开发速度
3.写代码时，多考虑代码可维护性
4.自己写的sql语句要对大致查出的数量级有数
5.多写日志，为了排查问题的方便
6.尽量别用自己的电脑，尤其是用来clone代码或核心文件
7.大家因为自己写跑数sql被说了，可以帮别人分担工作，但如果自己不能保障正确性就还是交给专业的人做

查日志用到的命令

1.tailf 文件名
	这个可以把日志输出，ctrl+c结束
2.cat -n 文件名 |grep "" --color -10
	在指定文件中搜索指定字符串，高亮显示，输出上下文10行
3.less 文件名
	这个查看文件可以翻页
4.ps -ef |grep 项目名
	查看指定项目的进程

IDEA常用快捷键

1.ctrl+shift+f(与繁简写切换快捷键冲突)
	用来在项目中全局搜索指定内容
2.ctrl+f
	用来在当前文件或页面中搜索指定内容
3.ctrl+n
	搜索指定类或文件
4.ctrl+alt+方向键
	光标返回上一处