首先，连接指的是传输层的TCP连接 连接就是连接，没有长短之说 是长是短取决于你是否关闭连接 建立连接后进行一次读写就马上关闭，这条连接对你来说就是短连接，如HTTP0.9, HTTP 1.0(默认关闭，支持Keep-Alive)就是这样 HTTP 1.1协议的headers中默认有Connection: Keep-Alive，告诉HTTP服务器不要关闭连接，后续的HTTP请求继续用这条连接，那这条连接对你来说就是一条长连接 另外，socket的SO_KEEPALIVE选项跟http中的Keep-Alive是完全不同的东西，前者是服务器在一条连接至少空闲2小时后发送探活包检测客户端是否还有响应，意在检测半开连接并关闭，后者前文应该已经说明白了。

国内服务器ping不通github，正好有一台香港的socks server，如果可以将http转发到这台server，问题就解决了。 privoxy是一款不进行网页缓存且自带过滤功能的代理服务器，针对http、https协议。通过其过滤功能，用户可以保护隐私、对网页内容进行过滤、管理Cookie，以及拦阻各种广告等。1 privoxy官网 大概意思是从http协议到其他协议的转换，另外可以做一些http内容的过滤、修改等。 安装privoxy（ubuntu） apt-get install privoxy 默认privoxy服务已经通过systemctl管理，systemctl status/stop/start privoxy查看/停止/启动privoxy 配置文件在/etc/privoxy/config 在文件末尾加上forward-socks5 / host:port . 将host:port替换成你的socks local server 最后按个.表示转发到socks server之后不用再转发到某个http server了 如果想这个privoxy服务可以被外部访问的话，比如本机通过这个privoxy进行科学上网，可以将配置文件中listen-address 的localhost改成0.0.0.0 最后，重启服务: systemctl restart privoxy https://zh.wikipedia.org/wiki/Privoxy ↩︎

看下面这个方法: public static JSONObject call(byte[] img, String algName, String algUrl) { long startTime = System.currentTimeMillis(); try { HttpResponse resp = OkHttpUtil.post(algUrl, MediaType.parse("application/octet-stream"), img, connectTimout, readAndWriteTimeout); // 省略代码块... } catch (Exception e) { // 省略代码块... } } 方法的入参是图片二进制流，模型名称和模型地址，方法的操作是用图片调用对应的模型，然后做一些日志记录、监控指标上报、错误处理等操作，最终返回模型的json格式结果。 可以看到其中模型的调用方式是确定的，直接将图片放在http body中，content-type为application/octet-stream 现在有一个模型，调用方式不一样，需要以form-data的格式把数据传过去，图片的名字必须为image, 像这样: OkHttpUtil.post(url, null, "image", img, null, 10000L, 10000L) 两者唯一的区别只是调用方式不一样，如果能把调用方式抽象出来单独传递的话，那是极好的。像Python这类的动态语言是很容易实现的，直接将函数作为参数传递，之后用()调用运算符调用即可： def func(): return "world" def outter(fun): print("hello, {}".format(fun())) outter(func) # "hello, world" 联想到Java中是否也可以这样呢，Java也是可以支持函数式编程的，自然也是可以的。实现方式如下 定义一个函数式接口: @FunctionalInterface public interface Lazy<T> { T value(); } 增加一个重载call方法，需要额外传入Lazy类型的参数httpHolder...

最开始写博客应该是大一下学期左右就开始了，当时是在CSDN上写，主要记录一些平时学习和开发时遇到的一些问题和解决方式的经验文章，也有一部分是算法题的题解。这是我CSDN主页地址，截止目前已经有10w+的访问量了。 后来觉得有自己的独立博客更酷一些，也整过hexo这类的博客引擎，觉得限制较多，部署繁琐，觉得从头到尾自己设计开发一个博客更拽，当时就真的开始从头写博客网站，数据库设计、后端接口、前端样式、简单的评论功能、后台管理，后台新建文章的页面样式都自己在大学宿舍里一点点地写，印象比较深刻的有两个地方，一个是实现了文章发布之后保存为静态文件，之后再访问时直接托管到nginx，请求不用到达后端。另一个是markdown解析器和代码高亮的调研，当时调研了好多的markdown解析，最终终于找到了自己满意的markdown-it，还实现了例如自定义图片大小和图片浮动方向的语法和对应的样式。之前那个博客的域名已经迁移到这里了，目前可访问的地址是https://123.206.178.92，之后会将那个博客的文章陆续迁移到这里来。 时间久了之后，发现维护起来比较麻烦，而且技术含量不高，就想选一个比较方便管理、扩展的博客系统，偶然的机会发现了typecho，发现挺不错，整个框架很轻，主题和插件修改起来也方便，而且是开源的，可以自己随便写一些扩展或者做一些修改。然后又找到了handsome 这款typecho主题，这是一款功能丰富、做的很用心的主题，虽然是收费的，但是没关系。后面会基于这个主题做一些样式上的设置和定制。 写博客是个好习惯，博客的本质是记录，记录自己的成长，记录自己的心得体会、对生活的感悟。写博客时就像跟自己对话，这种感觉有些微妙。 我的博客又开张了，希望自己坚持写下去。

信号的作用 信号是一种异步通知机制，用来告知进程一个事件已经发生 信号的产生 信号可以由用户调用kill命令发送，也可以由操作系统在某些事件发生时产生，如计时器到期、子进程结束、访问了不改访问的内存等。 信号的工作过程1 当一个信号发送给某个进程时，内核会查看该进程的PCB以决定改信号的处理方式，如果该信号的处理动作是SIG_IGN，则会忽略改信号，如果处理动作是SIG_DFL，则内核会找到该信号的默认处理程序地址并执行。 如果该进程定义了该信号的处理程序，则会执行该程序。 如果进程注册了信号处理程序，则会在进程的待处理信号表中添加一项。当进程下次被调度执行时，内核会首先往该进程的堆栈空间添加一些数据，然后改变执行指令的地址(相当于改变8086架构CPU的CS和IP寄存器的值)，就像进程自己调用了信号处理程序一样。 当信号处理程序结束时，会继续执行之前的代码。 内核通常需要知道信号处理程序何时返回，比如当信号处理函数执行时，需要阻止相当的信号被再次传递，或者当信号处理函数执行完后，需要重新调用被信号中断的系统调用。要做到这一点，还需要改变堆栈和指令指针。 内核怎么知道进程的信号处理程序结束了2 内核往进程中映射了一页内存，改内存中有一个用来通知内核处理程序已完成的系统调用，然后将信号处理程序的返回地址改为该内存页的地址(就是改变栈顶的值)。 how-do-unix-signals-work ↩︎ how-signals-work-internally ↩︎