stevenxyy的博客

第二: 强分代假说: 强者恒强, 一个对象如果能持久一段gc次数而不消亡, 他突然消亡的可能性就很小, 或者说越难以消亡)(是以下两条的讨论, 第一:弱分代假说: 弱者居多, 弱者就是指朝生夕死,

深入理解Java虚拟机书中有详尽描述, 本文做一下咀嚼.3.8.1 对象优先在Eden分配。3.8.2 大对象直接进入老年代。

调用栈里的引用类型数据是GC的根集合（root set）的重要组成部分；找出栈上的引用是GC的根枚举（root enumeration）中不可或缺的一环。要看JVM选择用什么方式。通常这个选择会影响到GC的实现。如果JVM选择不记录任何这种类型的数据，那么它就无法区分内存里某个位置上的数据到底应该解读为引用类型还是整型还是别的什么。这种条件下，实现出来的GC就会是“[b]保守式GC（conservative GC）[/b]”。

但问题是，栈上的本地变量表里面只有一部分数据是 Reference 类型的（它们是我们所需要的），那些非 Reference 类型的数据对我们而言毫无用处，但我们还是不得不对整个栈全部扫描一遍，这是对时间和资源的一种浪费。仍然是拿空间换时间的办法。但问题是，确实可能存在位于老年代的某个 GC Root，它引用了新生代的某个对象，这个对象你是不能清除的。一个很自然的想法是，能不能用空间换时间，在某个时候把栈上代表引用的位置全部记录下来，这样到真正 gc 的时候就可以直接读取，而不用再一点一点的扫描了。

但问题是，栈上的本地变量表里面只有一部分数据是 Reference 类型的（它们是我们所需要的），那些非 Reference 类型的数据对我们而言毫无用处，但我们还是不得不对整个栈全部扫描一遍，这是对时间和资源的一种浪费。仍然是拿空间换时间的办法。但问题是，确实可能存在位于老年代的某个 GC Root，它引用了新生代的某个对象，这个对象你是不能清除的。一个很自然的想法是，能不能用空间换时间，在某个时候把栈上代表引用的位置全部记录下来，这样到真正 gc 的时候就可以直接读取，而不用再一点一点的扫描了。

自增id坑:

mycli in docker

线程的阻塞和唤醒：当线程调用阻塞方法（如 Thread.sleep() 、 Object.wait() 等）时，线程会进入阻塞状态，这会导致线程从用户态切换到内核态。同步原语的使用：当线程使用同步原语（如 synchronized 、 Lock 等）进行同步操作时，如果发生了竞争或需要等待锁资源，线程可能会从用户态切换到内核态，直到获取到锁资源或竞争解决后再切换回用户态。需要注意的是，线程的用户态和内核态之间的切换是由操作系统负责管理的，具体的切换行为和开销可能因操作系统的不同而有所差异。

不知道理解是否偏差。

也就是, mq服务器持久化了所有消息(如果没达到7天过期的话), 消费者自己本地有记录消费位点, 也没有别的消费者来干扰你的消费位点. 所以不会丢消息。这里说的不会丢消息是, mq服务和设计支持. 但是没说支持重试. 消费失败或者说如果有必要持久化消费位点的话, 需要消费者自己处理.还是集群消费 (这当然更不会丢消息, 持久化和重试.提交消费位点都是封装好了的 只要别异常当做成功, 别业务侧再次并发消费就行)这压根不是广播好吗, 这就是发布订阅, 只不过是多个消费者订阅了同一个消息队列, 仅此而已.

partition维度 需要尽量错开主副本, 对节点数还是有要求的 (比如es), 节点少副本多是不太好的. 高可用受影响。尽量只要少数几个可写的文件 (所有主题共用一个, kafka是每个主题的每个副本各一个日志文件)按partition维度会造成文件个数增加, 磁盘io读写竞争增加。

2.带缓冲区的 BufferedOutputStream 性能提升的法宝就是：每次调用 write() 方法并不会产生实际的 write 系统调用，而是会先将数据存放于 BufferedOutputStream 实例内部的缓冲区中（缓冲区默认大小 8 KB），等缓冲区满、或者手动调用 BufferedOutputStream.flush() 或 close() 方法时，才会真正调用 write 系统调用将缓冲区数据写入 page cache。1.普通IO每次都会产生write系统调用。

1.场景一, 不用. 安排了网络线程池, 却没有受益, 或者是负受益, 如果本身就是同步场景, 业务线程必须要等待http结果才能处理下一步, 并且不能放在网络线程回调中处理(网络线程不能处理太慢的业务, 就像netty一样), 这种情况还是挺多的.2.场景二, 不满足场景一的, 比如, 调用方业务不用同步等结果, 可以在网络线程的响应回调中执行 (大不了多开点网络线程), 或者就只要调一个就行了, 对于响应的处理并不复杂耗时。是否需要使用nio?这个只讨论客户端就行了, 因为连接客户端发起的.

而当我们采用 [账号id -> 角色id -> 权限列表] 的缓存模型时，则只需要清除或修改 [角色id -> 权限列表] 一条缓存即可。通常我们系统的权限架构是RBAC模型：权限与用户没有直接的关系，而是：用户拥有指定的角色，角色再拥有指定的权限。而这种’拥有关系’是动态的，是可以随时修改的，一旦我们修改了它们的对应关系，便要同步修改或清除对应的缓存数据。：为什么不直接缓存 [账号id->权限列表]的关系，而是 [账号id -> 角色id -> 权限列表]？为了避免redis keys问题.

网络编程答疑融合连环tcp/nio/bio/redis/redisson/lettuce/netty/dubbo

但是这只是理想情况，因为并发量受限于系统能力而不可能持续上升，例如DUBBO线程池就对线程数做了限制，超出最大线程数限制则会执行拒绝策略，而拒绝策略会提示线程池已满，这就是DUBBO线程池打满问题的根源。我们首先分析一个问题：一个公司有7200名员工，每天上班打卡时间是早上8点到8点30分，每次打卡时间系统执行时长为5秒。如果系统为每一个请求分配一个处理线程，那么并发量可以近似等于线程数。基于上述公式不难看出并发量受QPS和RT影响，这两个指标任意一个上升就会导致并发量上升。并发量 = QPS x RT。

【代码】nginx openresty自请求get带url参数鉴权转发。

在这个例子中，BeanA和BeanB彼此循环依赖。如果调用任何一个@Async方法，都会由于循环引用而导致运行时错误. 假如这里让异步生效, 就会无限异步, 这个可能都没法检测, 因为是异步, 栈桢不再同一个, 也不是stackoverflow会无限提交异步任务。这个限制是特定于@Async的，并不适用于Spring的大多数其他方面的AOP。实际上，Spring的AOP被设计为以优雅的方式处理循环引用，只要它们不涉及异步处理。同时，这里是一个循环引用如何导致@Async问题的示例。

isSingletonCurrentlyInCreation(beanName) 正常都会是true.只要是正常通过beforeSingletonCreation走的.不要被迷惑了(并不是说循环依赖才true)所以强制一二三级缓存。

【代码】@lazy注入。