如果存在很多对象都只要 new 一次，或者每次 new 的参数都是固定的，那就适合 spring 。否则不适合。

长者表示他开发过程基本上很少 debug，逻辑异常都是通过运行日志来定位。

就我个人在调试代码的时候，一般用 assert+debugger，生产环境用日志。idea 可以打 AssertionError 的断点，assert false 就相当于进入断点，就我而言效果比日志强太多

第一种情况如 2 楼所说，第二点：Selector#select() 返回的是更新的 key 的数量。
我错了，取消 key 会在下一次 select 的时候执行这段代码
if (!ch.isOpen() && !ch.isRegistered())
((SelChImpl)ch).kill();
不能保证一定会关闭连接。不过关闭连接的时候，AbstractSelectableChannel#implCloseChannel()这个方法就是把所有键取消了

第一种情况
read()的注释
Returns:
The number of bytes read, possibly zero, or -1 if the channel has reached end-of-stream
read 返回-1 的时候就是已经读完了，下一次 read 就会抛已经关闭的异常。同时你忘了考虑返回 0 的情况。
第二种情况
select()的注释
Returns:
The number of keys, possibly zero, whose ready-operation sets were updated
select()返回 0 是退出的原因。为什么返回 0 我没法复现。

两个方法都隐式调用了对方，而且有标志位会只调用一次。不过 SelectionChanncel#cancel()是懒式，建议只调用 SocketChannel#close()。

客服端新建连接要用无参的 opne 方法，先设置为非阻塞然后注册再连接。
Selector#select()可能返回 0，你需要用 while true 。
建议不要用 iterator 而是用 jdk11 的 Selector#select(Consumer<SelectionKey> action)，或者模仿写一个：拷贝原来的 set，把原来的 set clear，然后循环被拷贝的 set 。
记得考虑 read 返回 0 和-1 的情况，返回-1 记得关闭连接。
不要用 while read，如果出现数据比 buffer 大，多半是 buffer 太小了。
read 之前一定要根据协议知道这一次要读的长度，等到满足长度以后再做相关操作。

@KeyboardManAnAn import ogr.context.水波纹

程序员要学数学吗？要，但是没几个程序员需要学会散度旋度复变函数。对于企业来说，十个能在一个月内生下孩子的孕妇比什么都强

一个轻量级的注入框架不到 500 行，可以自己写一个。大部分项目只用到 spring 很小一部分功能

java：
read(result-> dosomething());

kotlin:
val result = read();
doSomething();

java 没法在语言级别做到这样写异步代码

都进了国企还学什么互联网的技术。做自己想做的，像编译器浏览器数据库操作系统游戏引擎多好

@kaigong
陪跑就是滚动但是没有中奖的用户。

抽奖最关键的是要实现一个接口 List<User> randomUser(int batch)。只要这个接口返回的每个用户是真随机的，那么前端只要一直显示，等到按停止按钮的时候，不管是当前的用户中奖，还是在请求一个后台中奖，每个用户中奖的概率是相等的。

真随机和伪随机的区别是，伪随机需要一个种子，在种子相同的情况下，伪随机的每个随机数都是一样的。如果是随机分页的话，随机到的分页 offset 就是种子。(当然在这个抽奖里伪随机也可以)

只讨论真随机，也就是展示的所有中和不中的用户都是随机的，不会出现用户 aa 中奖，陪跑的全是 ab,ac,ad,据我所知 sql 必须遍历(欢迎打脸)。

既然这样把所有用户取出来放到 list 里。list 的前 n 位保存已经取出来的用户，后 m 位保存没取的用户，每次取用户随机一个 n 到 m 的数 x，所指向的用户就是中将的用户，然后把 list[n]和 list[x]做交换，n++;m--。

只要这样取，不管是取出的前 30 位，后 30 位中奖，都是随机的，都是公平的。而且中奖的用户和陪跑的用户没有关系。

木桶效应，你既然使用了国产手机，那么决定隐私又没有泄露的就不是用什么软件(国产可以去掉)

effective java

html 本质是 xml，用 xpath 语法比较好吧

https://s2.ax1x.com/2020/03/08/3vRQfA.jpg
https://s2.ax1x.com/2020/03/08/3vRKFH.jpg

hls 如果提前分包后台就不需要解码，后台就是个静态 http 服务器，甚至你可以把视频全扔给 cdn。视频的延迟完全取决于服务器带宽和用户的网速。

@simonlu9 hls 协议是下一个.ts 和.m3u8 文件，第一段视频的 io 时间就是两次 http 请求，你把每段视频的大小控制在 1m 试试？可以用 ffmpeg 推流到 nginx 上，环境搭起来很简单，选择合适的参数，全程只要部署改配置文件运行。

我干过摄像头的项目，在我走后安卓端改从 rtsp 改成 hls(理论 rtsp 更快但是既然选择了 hls 那说明 h5 是可以接受的)，mp4 的视频放在 cdn 上，加上视频清晰度不高只给内部用，按照同事的说法就是秒开。