可以先写个脚本，用 GaussDB 的原生连接方式，高并发的去 select 'x' ，比较一下用 PG JDBC 驱动连接方式高并发 select 'x' 的情况。如果一样，那就只是数据库的问题，交给华为去处理。如果明显不一样，那就很有可能是 JDBC 驱动的问题，还是交给华为去处理，因为 JDBC 驱动是数据库厂商负责的。

具体情况不是很了解。但并发量起来后才变慢、变慢但是最终会完成、跟踪到执行 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 自己就明确区分了数据加密保护跟全盘监控两个级别，你还在这里混淆监控跟数据保护，那是连非蠢即坏都算不上，是实实在在的蠢。