@yazoox #32 @ng29 #27
以前有一个 Socket 编程，具体是那个我也忘了，可能从来都是谬传，它的编程模型是服务器用一个端口监听，然后每来一个客户端就用另一个端口跟客户端反向连接用来维持跟客户端的连接。这种模型下，服务器端的并发连接数，自然要受端口数的限制。

但是上面这个是 Socket 编程模型的规定，不是 TCP 通信协议的规定。TCP 协议使用 4 元组来区分不同的连接的，这 4 元组是目的 IP 地址、目的端口号、源 IP 地址和源端口号，换更容易的说法，是 服务器 IP 、服务器端口、客户端 IP 、客户端端口。这意味着，你可以在服务器 IP 、服务器端口不变的情况下，通过客户端 IP + 客户端端口来区分不同的连接。故，理论上，你可以只是用一个端口，支撑无限大的并发连接。实际上当然不能支撑无限大的并发连接量，这个还要看服务器的硬件配置和操作系统对 TCP 连接的支撑模型。


另外，以上还没涉及负载均衡，如果涉及了，还要考虑负载均衡程序的编程模型。

/{idCode} 能够匹配任何 /*** 的 URL 。

云桌面已经走入市场了吗，不应该呀。之前试过华为云桌面，也不是不能用，但那收费可不是一般人能承受的起的。云上的成本是远高于本地的，如果好处仅仅是方面管理员工的电脑，这个傻子才会切换到云桌面。

对于隐私焦虑，你压根就没必要焦虑，公司的电脑不要干个人的事。忍一段时间自己买个笔记本用就行了，到时候日常工作用自己的电脑，公司的正式工作再放到公司电脑上提交。

在 unix/linux 下限制连接数的主要因素是内存和允许的文件描述符个数（每个 tcp 连接都要占用一定内存，每个 socket 就是一个文件描述符）。这个限制取决于服务器的配置，普通服务器 5 万就是极限了，再高得用贵死人的高性能服务器。而 Windows 环境，还是旧的 2008 系统，超过 5 万应该不是很容易的事。

@edis0n0 更正，原生 TCP 连接不受服务器端口号限制。TCP 使用由本地地址和远端地址组成的 4 元组：目的 IP 地址、目的端口号、源 IP 地址和源端口号来处理传入的多个连接请求。故，服务器只需要占用一个端口就可以负责监听和所有的连接。

@edis0n0 #2 单机十万并发基本不可能，程序可以支持这么高，但硬件和操作系统底层是不支持的，端口号总共才 65535 个（ Socket 连接时服务器只占用一个监听端口，但是对于每个客户端还得占用一个反向连接端口，原生 TCP 连接我不是太清楚）。

仅限个人经验，不值得去。没待过新能源行业，但是待过制造业的研发部门，非软件行业的软件开发，干起活来就像外面人眼里的修电脑的。就更别提国内非软件的研发，工业化程度低得要死，软件行业起码还有 CMMI/ISO 当遮羞布，非软件研发那真是纯手搓。

第一，设置成警告而非错误的原因，就是因为警告不是必须解决的，连警告都不允许是“水至清则无鱼”的行为。
第二，警告可以随时清理，也可以定期清理，但无论是哪种清理方式，都要是软件开发过程当中，而不是加班当中。

简单来说，就是这种情况，先找 QA ，别先找编码的人。

private Class<T> templateClz;

构造器上中
templateClz= (Class<T>) ((ParameterizedType) getClass().getGenericSuperclass()).getActualTypeArguments()[0];

然后 public T code(String code) 这个方法就能正常用了。

有限制条件，就是子类必须像你写的那样继承，即必须继承 BaseClass<SomeClass>，且这个 SomeClass 只能声明一次，后面再继承的类，T 是固定成 SomeClass 的，不能换。

另外这个实际上解决的是，抽象父类中怎么获取子类的泛型的问题，这里正常的用法应该是 public abstract class FrontResultBuilder<T> , T 跟 FrontResultBuilder 没有继承关系。

这种方法是用了泛型的黑科技，来自于 Hibernate ，现在已经基本不用了，用注解会更方便。

@orangex #12
CPU 全虚拟化的时候（没开 VT 的 Vmware ），虚拟机跟 JVM 是差不多的，对于宿主机来说，就是个普通应用，这时候不会出现虚拟机内部闲着但是宿主机资源被占用的情况。

开 VT 半虚拟机化的时候，Hyper-V 这边是虚拟机跟宿主机一起调度，只能人为给虚拟机加限额，这时候虚拟机内部的 CPU 跟宿主机 CPU 是一体基本没区别的，也不会出现虚拟机内部闲着但是宿主机资源被占用的情况。其他虚拟化技术可能有出去，但大体是类似的。VT 虚拟化，基本都是在 CPU 的线程调度上入手。

以上仅限于 CPU ，或者也包含 GPU ，内存部分，即使是动态增缩内存，虚拟机都是独占的，分配不好就会出现虚拟机闲置但宿主机不够用的情况。

我搜了一圈，没有找到区分 unload 是刷新还是关闭的方法，也就是说没有标签页关闭事件（ windows.onclose 还在试验中）。所以这个每必要再研究下去了，就是不可实现的需求，怼回去。就留一个长时间未操作服务器端自动退出就可以了，浏览器端就别搞骚套路了。

还是遇到难题了，新建标签页跟刷新事件很好区分，但是关闭标签页跟刷新事件，不好区分。

刚去看了下 localStorage 、sessionStorage ，发现 sessionStorage 是基于标签页的，这样是有办法监控当前域名打开的标签页的个数的。

思路就是：
用与标签页无关的 localStorage 存储计数，每打开一个标签页就加 1 ，每关闭一个标签页就减 1 ；
用于标签页有关的 sessionStrrage 结合 load unload 事件来触发标签页打开和标签页关闭事件，主要是把刷新标签页给区分出去，怎么区分还要仔细想一想，不是太好处理。
给 unload 事件加个监听，通过 localStorage 的计数，来判断是否需要触发登出处理，也需要区分刷新跟关闭。

不嫌 LOW ，不怕性能爆炸，并且还不关心是否长时间没操作的话，把会话超时时间定为 1 分钟，然后每个页面都弄个 30 秒的定时器触发垃圾请求，也能大力出奇迹。

那些让后端处理的，你们是哪里学的开发，浏览器的事件有没有触发，服务器端要拿头去判断吗。现行 HTTP 规范下，只有标签页关闭和窗口关闭两个事件，没有特定标签页全部关闭事件，这事拿常规手段做不了。

我想到一个思路，需要前后端配合。前端，每个页面定时上报自己还活着，可以用 websocket 加心跳，也可以就是单纯的 JavaScript 定时器（如果标签页是频繁打开关闭的，那就千万别用 websocket ，DDOS 了）。后端需要监控当前 Session （如果能定位到客户端也可以把维度换成客户端）的“活着的页面数”，变成零的时候就触发登出操作。

但是，跟产品沟通一下，把需求变成“5 分钟或者半小时内没操作就自动登出”，回是更好的选择。

打算长期用的东西，买的时候要直接忽略首年价格，直接看续费价格。订阅性的服务，首次付费都是给你低价试用的。

你的工厂方法从底子上就是有问题的，没法破。工厂方法是主类的辅助类，可以是主类的内部类，但绝对不能跟主类有继承关系。

继承关系上也有问题：构造方法和静态方法都是不能继承 /覆盖的。

虚拟机又不是独立硬件，它卡的时候宿主机自然跟着卡。

再去看看商店，商店微信有两个的，老的那个是 UWP 原生独立开发，属于独立应用，早就没人维护了。新的那个是 Win32 转制 UWP ，也就是半维护状态。