企图变秃变强的第一天

时间:2022-07-26
本文章向大家介绍企图变秃变强的第一天,主要内容包括其使用实例、应用技巧、基本知识点总结和需要注意事项,具有一定的参考价值,需要的朋友可以参考一下。

2020.7.22

好记性不如烂笔头

1.MyBatis-Plus之saveOrUpdate

我需要写一个保存/修改的接口,嗯,写呗,没人拦着你。 怎么写…

来自官网的注释:

    /**
     * TableId 注解存在更新记录,否插入一条记录
     *
     * @param entity 实体对象
     */
    boolean saveOrUpdate(T entity);

	//然后斗胆瞅一眼源码:

    public boolean saveOrUpdate(T entity) {
        if (null != entity) {
            Class<?> cls = entity.getClass();
            TableInfo tableInfo = TableInfoHelper.getTableInfo(cls);
            Assert.notNull(tableInfo, "error: can not execute. because can not find cache of TableInfo for entity!");
            String keyProperty = tableInfo.getKeyProperty();
            Assert.notEmpty(keyProperty, "error: can not execute. because can not find column for id from entity!");
            Object idVal = ReflectionKit.getMethodValue(cls, entity, tableInfo.getKeyProperty());
            return StringUtils.checkValNull(idVal) || Objects.isNull(getById((Serializable) idVal)) ? save(entity) : updateById(entity);
        }
        return false;
    }

首先判断传入的实体是不是null,如果是null,哪玩完,上帝都救不了你,送你一个false,下次再来。然后断言TableInfo(数据库表反射信息)是true,如果是false,再下边是判断主键,如果false,丢给你一堆msg,说你没设置TableId,如果传了,就调它的update方法,如果没传,就调save方法。

2.Dubbo调用超时

今天遇到了Dubbo的consumer调provider超时的问题,Dubbo默认的调用时间默认是1秒,默认重复三次,如果一秒内返回不成功会报一个调用超时并打印日志,我百度了一下,大部分都是通过配置xml的形式,与我需要的不符,后来请教阳哥,最后决定在**@Reference**上设置timeout,格式是:@Reference(timeout = time),以毫秒为单位,刚刚看到一篇文章,简单列举了设置超时的优先级:

注解式>dubbo.properties中“dubbo.service”>xml中dubbo:provider >dubbo.properties中“dubbo.provider”

3.数据库表死锁

我在用postman做测试的时候,遇见了MySQLTransactionRollbackException: Lock wait timeout exceeded,第一次遇见这个,然后度娘搜,找了一下原因:当数据库在执行语句时,会把表锁住,直到commit 或者 事务失败导致回滚数据还用就是退出数据库用户 ,所以我觉得是我对数据库进行操作的时候,另一块代码也对改表执行了操作,由于并没有commit,所以出发了锁,由此我想到两个概念,乐观锁和悲观锁,乐观锁假设数据一般情况下不会造成冲突,所以在数据进行提交更新的时候,才会正式对数据的冲突与否进行检测。悲观锁是当要对数据库中的一条数据进行修改的时候,为了避免同时被其他人修改,最好的办法就是直接对该数据进行加锁以防止并发。现在只看到了概念,还需要深入理解。

死锁的解决:

-- 查询有没有出现死锁的表
show open tables where In_use>0;
-- 查询出那个进程(id)是出现了死锁
select * from information_schema.innodb_trx;
-- 然后杀掉它
kill id;

-- 还有另一种语句是同样的作用
show open tables where In_use>0;
show processlist
kill id;

-- 经过尝试,个人觉得第一种方式比较好,以后可能就用第一种了,但是我不希望以后出现这样的问题了...
-- 不过用show processlist的好处就是可以查看状态等消息。

4.还有一个最重要的习惯:

一定要先想好再动手做,不然会返工。 先写文档 今日事,今日毕。别拖延 多听取建议