具体情况不是很了解。但并发量起来后才变慢、变慢但是最终会完成、跟踪到执行 SQL 阶段慢的背景，看起来很像是数据库单点阻塞，应该先从数据库那里找问题。此外，这里是用 PG 的 JDBC 驱动去连接 PG 的衍生数据库，JDBC 驱动兼容性上也可能有问题。

取决于人数。一个人的话，非但不省钱，还会长胖。此外，人数越少，越容易造成单一饮食带来的营养不均衡。

人家打得就是打一枪换一个地方，能骗一个是一个的套路。发帖避雷或者封号什么的，屁用没有。楼主这种对网络上不认识的人，认爹认朋友的行为，才是应该拿来避雷的。

一般的权限管理组件只管到 URL 资源这一级别，不会往下再管，而你这个是业务逻辑权限，需要下层代码手动处理，或者更高级/复杂的权限管理组件。

拖发工资更多的是对公司士气和外部经营的影响，但你要走到法律责任的时候，比芝麻粒还小——拖发几个月最后只要补上就行，连滞纳金都没有。所以，这才刚开始就让签字的，那是准备直接不发了，你确实提年假了。

最优解就是硬刚拿第二批裁员补偿。一般情况下，磨洋工白拿工资吧。关键点有两个：一，你不需要明确拒绝，但一定不要签下同意，并且灰色福利该不要就不要——比如迟到了就让扣钱不要补灰色卡；二，一旦工资没有按时发放，那么就该转变成即时止损策略了。

@bler #9 a 、b 两个是直连的，他们不经过公网上其他地方的中转。

通过端口转发等措施，即使是内网机器，也可以在公网上开放端口。这个开放的不是完整 IP ，而是一个 IP 加特定端口，但 TCP 连接有端口就够了。NAT 网络中，不管是 BT 下载，还是电驴下载，还是点对点聊天，开启 UPnP 是必要条件。

不过 UPnP 或者其他端口转发措施，是网关/路由器提供的，家里的路由器可以自己开，运营商那里的网关是铁定不会开的，所以一旦运营商给的就是内网 IP 那就直接歇菜了。但是，TCP 连接只需要被叫端在公网就可以连得起来，故 a 、b 两个只要有一个在公网有端口，就可以连得上。这在 BT 下载的表现上是：如果你在内网，那么能看到很多主机，但是只能连接其中在公网上的；如果你在公网，那么你看到多少主机就能连接到多少主机。这个在非服务器建主的对战游戏中也有表现：如果你在内网，那么你只能进别人的主机，你建的主机别人进不了。

首先纠正一点，UDP 是不需要回复确认，不是不需要建立连接，可以认为它是单向连接。UDP 因为是单向连接，如果双方要相互沟通数据那么双方都得在公网上，这点反而不如 TCP 。

补上 2 点，就是 BT 下载的方式。
1 ，a 、b 跟 tracker 之间，只会沟通用户 a 、用户 b 的信息，不会传递真正的数据文件。跟 traker 之间的沟通，UDP 、TCP 皆可，不过如果是正常网络那么 TCP 就很浪费。
2 ，a 、b 各自从 traker 获取到对方的信息之后，a 、b 之间就抛开 tracker 直接建立 TCP 连接，然后相互传递文件数据了。a 、b 之间，最少有一个要有公网端口（ NAT 出来的端口也行），否则是无法建立 TCP 连接的。

同源策略是浏览器端的安全控制措施，不是服务器端的，你反代个毛蛋。

划重点：「 B 站，咸鱼等 app 」

不得不提一下，月薪请假，不管按照 21.75 ，还是 22 天计算扣钱，都有坑。比如 10 月请假 19 天，即实际上 10 月一天都没上班，公司照样得发 3 天的工资。这个坑只要过年放假员工多请几天假就会爆出来。正确的做法，应该是：如果出勤天数大于 11 ，那么工资就是{月薪} - {月薪/21.75} * 缺勤天数；如果出勤天数小于 11 ，那么工资就是 {月薪/21.75} * 出勤天数。这个 11 取得是 21.75 的一半，可以按照实际情况去换。

月薪请假，还有一种计算方式是，按照 {月薪} - {月薪/当月应出勤天数} * 缺勤天数，即{月薪/当月应出勤天数} * 出勤天数的计算方式。看起来很公平，但实际上更坑。财务做预算骂娘还是小事。员工 10 、1 、2 月不请假但也不出活，7 、8 月期间该忙的时候疯狂请假，这才是大问题。

@Sting #73
@poorcai #75

楼主的算法，就是日薪 363.6+按照出勤天数计算，但同时又期望了保姆长期干。哪天楼主来兴趣了请假一个月自己带娃，保姆就直接一个月零收入并且还不能另找超过一个月的其他工作（当然实际上保姆会直接不干）。

如果你要按照出勤日计算，那么你不过多久结算一次，都是日薪，最终都是日结。在此情况下，保姆事实上具备随时第二天请假，以及随时第二天就走人的权力，不管你给不给这个权力。实际上来说，通常，能接受按日计算工资的保姆，也只会做短期打算。

要么日薪，剩下节假日的钱，但接受保姆不稳定的风险。要么月薪，节假日当作福利，但是保姆会很稳定。你要保姆长期稳定干，又不给人月薪福利，那是想吃屎。

你这个很明显跟 public static final int FIRST_LINE_HEIGH 没关系，跟 ScreenUtil.dp2px(80) 有关系。

80dp 的高度如果是静态值，那么请直接把它赋值给 FIRST_LINE_HEIGHT 。如果是动态值，那么请不要赋值给 static final 类型的「常量」，给常量设置一个可变值，即使是仅取第一次的值，那也是找抽。

你现在是装了一个权限比操作系统还高的超级后门，它可能确实没干，但它要想干随时就能干。

这种系统，有一个名字更贴切：（公司对员工）零信任防护系统。信任是双向的，公司对员工零信任，员工也要对公司零信任，在装了零信任系统的公司电脑上，不要放任何员工的个人内容，包括笔记这种零碎个人资料。

@wdlth #10 ip-guard 自己就明确区分了数据加密保护跟全盘监控两个级别，你还在这里混淆监控跟数据保护，那是连非蠢即坏都算不上，是实实在在的蠢。

搜索结果上的是摘要，快照是快照，这是两码事。

六，响应式编程，对应的编程概念是「流」，现实概念有个跟起非常像的，「流水线」。如果要搞这个，首先要把「流」搞清楚。Java8 的 Stream 可以用来入门。Kettle 、Spring Batch 可以用来练手。你最起码是 kettle 或者 Spring Batch （高级流应用，不能是一个处理器转发然后又回到普通代码去处理了） 用得比较熟悉了，才能去接触响应式编程。另外，你也可以直接从函数式编程、数据流，这些数学理论入手，不过前提是要先清空 C 、C++、Java 等全部常规编程习惯。

一到五跑题了，留着备用看吧。

一，同异步跟是否阻塞，不是一词两用，而是有关联的两个概念。

二，阻塞针对的不是当前过程，而是使用同一资源的多个过程之间的协作方式。通常都是 IO 比计算慢，故常见的阻塞是针对 IO 的阻塞。一个 IO 通道，如果只允许同时最多一个过程使用它，在该过程使用它期间其他过程只能等，那么这就是阻塞的。如果允许同时多个过程使用它，那么这是非阻塞的。

三，同步异步，针对的是调用者和被调用者之间的协作过程。如果被调用者不做完就不回复，同时调用者还一直等着它，那么这是同步的。如果被调用者没处理完就提前做个特殊回复，同时调用者认可这种特殊回复，那么这是异步调用。如果调用者这收到异步特殊回复之后，又再继续等待这个特殊回复转换成完整回复，那么这是异步之后的回转同步，或者，整体上来说，这还是同步调用。

四，再往外看调用者、非调用者的宿主程序，这时候同异步跟阻塞有了关联。如果把调用者宿主程序认为资源，调用关系——被调用者的执行行为认为处理过程，那么同步调用是阻塞的，异步调用是非阻塞的。

五，同步还是异步，技术上由被调用者决定，但业务上由有调用者决定。如果调用者实时关心回复结果，那么它永远要是同步调用，即使被调用者技术上异步，最终也要通过异步转回同步来变成同步。异步编程中，如何异步从来都不是关键，如何异步转会同步，获取去掉不必要的业务同步，才是关键。