问题 ：https://leetcode-cn.com/problems/spiral-matrix/

解：https://gitee.com/footmanff/leetcode/blob/master/src/main/java/com/footmanff/leetcode/P54.java

直接模拟旋转，处理一些边界条件比较麻烦，wrong 了好几次。

Read More ...

问题：https://leetcode.com/problems/merge-k-sorted-lists/

解：https://gitee.com/footmanff/leetcode/blob/master/src/main/java/com/footmanff/leetcode/P23_2.java

Runtime: 6 ms, faster than 54.03% of Java online submissions for Merge k Sorted Lists.

Memory Usage: 41.4 MB, less than 59.41% of Java online submissions for Merge k Sorted Lists.

解法是对 ListNode array 头部数字排序，然后每次对第一个位置的 array 执行出队，出队以后，利用重新对所有 array 排序（冒泡），并重复执行上述过程。

要再找个更优解法。

问题

1. @Transactional 注解标注的申明式事务是用 AOP 实现的，那么事务逻辑是怎么织入的呢？
2. 织入的事务逻辑，是怎么处理连接的？底层的 dao 实现也需要连接，应该是用 ThreadLocal 做的，那么具体是怎么实现的？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

public abstract class AbstractBeanFactory extends FactoryBeanRegistrySupport implements ConfigurableBeanFactory {
  // ...
  sharedInstance = getSingleton(beanName, new ObjectFactory<Object>() {
    @Override
    public Object getObject() throws BeansException {
      try {
        return createBean(beanName, mbd, args);
      }
      catch (BeansException ex) {
        // Explicitly remove instance from singleton cache: It might have been put there
        // eagerly by the creation process, to allow for circular reference resolution.
        // Also remove any beans that received a temporary reference to the bean.
        destroySingleton(beanName);
        throw ex;
      }
    }
  });
  // ...
}

Read More ...

问题

事务执行的代码：

1
2
3
4
5
6

@Transactional
@Override
public CheckResult check(TradeCheckDO tradeCheckDO) {
  // 一次查询，查询库A A1表
  // 一次查询，查询库B B1表
}

这里的问题是第二次查询，在执行 select … B1 时，没有在 B 库上执行，而是在 A 库上查 B1 表，就报错了。这个原因应该是数据源（DataSource）用的是动态数据源，导致没有重新获取连接。

Read More ...

背景

最近在优化 ES 的搜索性能，其中有一个优化点是避免对 nested 结果的使用，对 nested 结构内的字段查询时候，相对不非 nested 结构的字段，性能会有损耗。本文不去具体说这个损耗的原理，只说解决办法。感兴趣的可以看看这篇文章：https://www.jianshu.com/p/f0a15e21f61b。

Read More ...

状态机是怎么定义，或者说是怎么抽象的？

• state 状态
• hierarchical state 子状态，具层级关系的状态
• region 域，区域
• transition 过渡，分三种类型，external、internal、local
• guard 守卫，相当于一种拦截，在某一个操作前设置一个 guard，用 guard 来校验到底是否执行后面的操作
• action 一次业务逻辑执行，执行参数 StateContext
• StateContext 状态上下文

Read More ...

2018 年刚过几天，是时候总结一波了。

Read More ...

最近在用 spock，但是搭环境时候碰到一个依赖问题，这里记录下解决过程：

为了使用最新版的特性，引入的 spock 的核心依赖是这样的：

1
2
3
4
5
6
7
8
9
10
11
12

<dependency>
    <groupId>org.spockframework</groupId>
    <artifactId>spock-core</artifactId>
    <version>1.2-groovy-2.5</version>
</dependency>

<dependency>
    <groupId>org.spockframework</groupId>
    <artifactId>spock-spring</artifactId>
    <version>1.2-groovy-2.5</version>
    <scope>test</scope>
</dependency>

Read More ...

背景

本来想搭一下 Spring-Boot 组合 Spock 做单元测试，弄了一个很小的 demo 项目测试，结果等到运行的时候 @Resource 注释不生效，bean name 也没错。反而 @Autowired 是能成功注入的，这个真的是奇了怪了。项目大概是这样的：

1
2
3
4
5
6
7
8
9

@SpringBootConfiguration
public class App {
    public static void main(String[] args) {
        ConfigurableApplicationContext applicationContext = SpringApplication.run(App.class, args);
        A a = applicationContext.getBean(A.class);
        B b = a.getB();
        System.out.println(b);
    }
}

Read More ...

分片不宜过大，在故障恢复的时候会更大的影响集群。

The shard is the unit at which Elasticsearch distributes data around the cluster. The speed at which Elasticsearch can move shards around when rebalancing data, e.g. following a failure, will depend on the size and number of shards as well as network and disk performance.

TIP: Avoid having very large shards as this can negatively affect the cluster’s ability to recover from failure. There is no fixed limit on how large shards can be, but a shard size of 50GB is often quoted as a limit that has been seen to work for a variety of use-cases.

ES 只新增数据，不更新数据。更新也只是把旧的数据标记删除，再新增新的数据。被删除的数据在段合并前，是会一直占用资源的。有一种思路是按时间区间将数据分成不同的索引存储，比如 2017 年一份索引、2018 年一份索引。这样索引会更小，每次进入下一个年份都有机会调整分片数量和索引结果，冷数据也可以按年进入归档状态，不会影响在热数据上的业务服务。

Read More ...