为什么 i 调大会发现基本上所有线程都出现的原因 有两个:
- 1.并发一种是硬件上的实现 并行，一种是软件上的实现时间片，而后者既然是时间片就牵扯到上下文切换，如果单个线程执行的周期小于上下文切换的周期，那多线程反而有时不如单线程快，比如 1：4 的关系 1 个时钟周期执行任务 4 个时钟周期执行上下文切换开四个线程反而没有一个线程要快，这也是为什么会看到并不是一个任务切换一次线程的重要原因，也就是线程执行并非是有序的，就不能按有序的思维去看待;
- 2.另一个原因是 如果一个 MyProducer 线程执行完 10 次会出现什么情况,显然并不会再去调用 producer 方法 那既然不调用 producer 方法 log.info 又怎么会打印呢

```
public void run() {
int i = 10;
while (i > 0) {
waitAndNotify.producer();
i--;
}
}
```
i 调大一些

核心是每个元素并不是第一个是第一个线程第二个是第二个线程，产生的第 n 个元素并非是 n%20, 线程的执行并不是有序的，所以并不会均匀分布，这里你可以对生成者的 list 进行改造 如 List<DataInfo> DataInfo {threadName,num}再看一下打印结果

32 楼给了思路，还有另一种方式 就是 能否 100w 分批查 与分批计算，否的话就让对象尽量的小 而非有过多冗余信息

@shintendo : 文章或项目还真没有留意到，个人的看法是控制好抽象的层数和命名，关于为什么是 7 层以内，最好是 3-4 层 往下，之前看过一篇刘未鹏老师的文章，讲到了一个工作记忆(其实我们意识的窗口很小，我们的工作记忆只能容纳寥寥数个条目)，
```
人在思考一个问题的时候，就像是在黑暗中打着电筒往前走（事实上，我们的工作记忆资源是有限的，有研究证明我们只能在工作记忆里面持有 7 加减 2 个项目；此外认知负荷也是有极限的），每一步推导都将我们往前挪一小步，然而电筒的光亮能照到的范围是有限的，我们走了几步发现后面又黑了，想到后面就忘了前面的，想到某个分支上去就忘了另一个分支，我们常常想着想着就想岔了，想岔了也就罢了，问题是一旦想岔了太远，就很难回到当初岔开的地方了
```
还有另一点是用好聚合和管理好代码的正交性，前者聚合是一种代码关联性比较强的关系可以放在一个包下，名字如 Todo ，TodoItetm 放在 todo 包下然后放在业务模块包下，这里 TodoItem 的创建依赖 父节点 Todo 是否创建；后者正交性则是我们理论上能达到代码复用性的最好状态，不依赖具体的父节点，如 Input button 这种 ，也就是一个函数具体实现的改动对另一个函数造成的影响要尽可能的小最好是无，而强依赖性显然会增大影响，写代码没有完全正确的模式，写的过程中慢慢找到“对就是这个感觉”，祝渐入佳境。

@lancelock 哈哈哈，这就是楼主为啥混乱了，数组 字典 明明是一个写法啊

不是邪教做法，没有什么缺陷，只是会增加逻辑的层数，抽象并非越多越好，只要是方便理解就可； vue 的单组件本质就是一个生成代码的模板,Composition API 之前 好像是 vue2.6 之前，复用手端有组合 、混合但粒度比较粗，最细的粒度就是函数了，这也是 Composition API 出来的原因，至于 Composition API 是只有 js 还是 html css 都包含，我个人站前者，原因是后者那样其实又回到了组件了 逃 （但是只要利于理解也没关系，但是会混乱，越简单越好）；所以 Composition API 也好，混合也好，继承也好，代码写出来是给人看的，只要容易理解易于维护就好。个人认为 Composition API 层数最好要控制在 7 层以内，最好是 3-4 层 往下。

对于这个语法糖 还是站 json 的写法，原因就是 当用数组'[]'时习惯的期望值是内存的连续空间 ，而使用结构'{}'时则更倾向与离散空间, 这个语法会导致思维的负担

@summerLast 0 1 2 解释器自动填充，一个语法糖罢了，但是好像这个玩意也可以做成结构的载体 可以做成数组的载体 至于底层内存分配是连续的空间或是离散的则被屏蔽掉了，用起来简单了，但也让楼主分不清为啥这样了，哈哈哈哈

@lancelock 没有用过 php,但我好像可以理解为啥这样，哈哈哈 数组变成了字典的子集 如 [0:"a",1:"b",2:"c"] 前面 0 1 2 不写的话可以这样 ["a","b","c"] ，不知 php 是不是这样

123 分母一个

这是自己封装的例子 可以 事务注解一块修饰 并且能锁住事务
@DistributedLock("wallet:walletId@#{accountId}@#{shopId}")
TradingFlow addTradingFlow(String accountId, String shopId, String outerCode, Long amount, TradingFlowTypeEnum type, String remark)

但是要注意 不要内部 方法调用 事务会失效 如 a.method(){this.dotran()}

核心就是改成串行 java 相关的话 可以用 RedisLockRegistry 这个

同一楼 final 字段 + 构造方法注入 + lombok 的 RequireArgsConstructor 注解
补 需要 注入值的 或 特殊的 不用 final 修饰 自己手动加对应注解

一样的方式，但有的时候没这个严谨

YOGA

对扩展开放 对修改关闭 核心是怕修改引入新的问题 ；
如果 没有引入新的问题而且行为表现一致的化 是可以修改的 ，假如代码已经腐烂了，是在腐烂外面一层层的包裹 最后腐烂的代码成为了软件珍珠 还是重构这是权衡之后做出的选择。
很多时候你会发现有很多相对立的概念好像都对， 核心是缺失了上下文导致的，而这些对立的概念其实就是一种策略，策略也是需要有上下文来决定使用那种更好一些，不要去迷信各种模式，他们是抽象的概念 既然抽象必有信息的丢失，找到自己写代码的感觉

入门看视频，一手资料看文，两者可结合，无好坏之分，深入看源码，选适合自己的