Java 的线程安全,以及死锁
刚才面试的时候被问到了关于线程安全和死锁的问题,有点露怯,故赶紧查漏补缺,记录于此。
刚才面试的时候被问到了关于线程安全和死锁的问题,有点露怯,故赶紧查漏补缺,记录于此。
Filter
是 Servlet
规范制定的,受 Servlet
容器支持,接口定义在 javax.servlet
包中。Filter
是被 Web Server(如 Tomcat
)调用。Filter
需要在 web.xml
中定义之后才会起作用。Filter
只在请求的前后起作用,Servlet
对于 Filter
来说是一个黑盒。Filter
的执行顺序是:void init(FilterConfig)
- 容器在初始化 Filter
时调用,在 Filter
生命周期内仅会被调用一次。方法可以抛出 ServletException
。doFilter(ServletRequest, ServletResponse, FilterChain)
- Web 容器每一次请求都会调用该方法。该方法将容器的请求和响应作为参数传递进来, FilterChain
用来调用下一个 Filter
。void destroy()
- 当容器销毁 Filter 实例时调用该方法,可以在方法中销毁资源,该方法在 Filter 的生命周期只会被调用一次。Interceptor
是 Spring
容器内的,由 Spring
框架提供支持。接口 HandlerInterceptor
定义在 org.springframework.web.servlet
包中。Interceptor
是被 Spring
调用。Interceptor
可以深入到方法前后、异常抛出前后等,比起 Filter
有更大的弹性。Interceptor
还允许用户介入请求的生命周期,可以在请求过程中获取信息,通常与请求更加耦合。Interceptor
的执行顺序是:DispatcherServlet
DispatcherServlet
将请求发送至 Interceptor
,Interceptor
执行 preHandle()
方法Controller
Interceptor
执行 postHandle()
方法最近折腾了下用 Tailscale 搭建虚拟局域网,在这里记录一下折腾的过程和一些心得。
就在刚刚,我一个误操作,在没有本地备份的前提下,force push 了一个 GitHub 上的仓库。万幸最后恢复成功,数据拿回来了。惊魂未定之余,在此记录我的抢救过程以供参考。
前段时间瞎折腾,给自己的黑莓 Bold 9900 写了个通过 NTP 同步时间的小工具,顺便在这里记录一下我在实现一个 NTP 客户端时对这个协议的理解。
太长不看:关闭 IPv6 或许可以解决。如果你平时要用到 IPv6,那就在更新之前先禁用 IPv6,更新完了再打开;如果开不开 IPv6 对你来说没区别的话,那永久关闭也不是不可以。当然如果你愿意,下文提到的改注册表的方案也是可用的。
这两天在给微软模拟飞行下载更新的时候,就算挂着网易 UU,速度也一直很慢,时常在 0.5MB/s~5MB/s 之间波动,不论怎么换节点也不能跑出正常的速度。今天经过一顿上网冲浪,发现这个问题的根源,在 IPv6。
其实网上针对这个问题已经有一些解决方案了,但内容看下来都一样,不外乎教你怎么关掉 IPv6。但我一方面要用到 IPv6,另一方面也不想那么粗暴的解决问题,所以又稍微做了点研究,顺便写了个小工具方便其他有这个问题的玩家。 经过一段时间的试用后发现,临时 / 永久关闭 IPv6 实际上是最优雅的方案……
联动上一篇博文,在解决了 OpenResty 上那个 SNI 的问题之后,我们发现有一个 Java 应用也有类似的问题。而最后发现,这是因为我们当前版本的 Java 中有一个 bug……
简单来说,就是在 Java 1.8u141
之前,HttpsURLConnection#setDefaultHostnameVerifier()
方法会破坏 SNI,而正好我们的代码里有这么一行:
1 | HttpsURLConnection.setDefaultHostnameVerifier((hostname, session) -> true); |
翻了下框架的代码,发现如果我不设定这个值,框架也调用这个方法来指定它默认的 hostname verifier;而如果我传个 null,那么它会抛个异常给我。所以,代码层面没有很方便的解决方案。
无奈,最后决定,先临时换了个没开启 SNI 的域名,暂时解决掉问题,然后升级 Java 到 1.8u181
,一劳永逸。
终于,我也有机会理直气壮地喊出 “这是 Java 的 bug” 了!(笑
[^1]: Extended server_name (SNI Extension) not sent with jdk1.8.0 but send with jdk1.7.0
[^2]: Custom HostnameVerifier disables SNI support on client in Java 8
前段时间,我司出现了一次生产事故,调查后发现是当时的 OpenResty 配置不兼容 SNI 导致的。在这里我也记录一下整件事的排查过程,以及解决方法,供遇到类似问题的同志们参考。
前段时间在网上看到了一个叫 “甜糖星愿计划” 的东西,声称可以通过贡献闲置带宽来获得积分。正好我有个 NAS,正好我的宽带一天从白天闲到黑夜,不如利用起来,少少挣一些零花钱。
需要注意的一点是,本文提到的镜像仅在我的群晖DS218+
上测试过,虽然镜像中未使用任何群晖限定的依赖,理论上适用于任何 x86 架构的平台,但并不保证运行效果。而且本文目标平台是 x86,如果你拥有 ARM 平台的机器,那根本不需要废这个劲,你可以直接运行甜糖星愿的可执行程序。
本文提到的操作全部基于 Docker,故在按照本文操作前,请先确保你已经拥有足够的知识来使用 Docker
和 docker-compose
。
由于我司目前的项目都运行在 Google Cloud Platform (以下简称 GCP) 上,那么自然而然的,我们选择了使用 GCP 的 Logging 来查看日志。在使用过程中,我们发现了一个问题,那就是我们无法直观的看到日志是从什么地方打印出来的,经常需要通过日志内容,在代码里面通过全文搜索来定位。这样就产生了一个需求:可不可以把这条日志所在的类、方法,和行数一起打印在日志中?