accept

查询有哪些端口是开启的: [ root@centos7 ~ ] # firewall-cmd --list-port 开启端口 [ root@centos7 ~ ] # firewall-cmd --zone=public --add-port=80/tcp --permanent 重启防火墙： [ root@centos7 ~ ] # firewall-cmd --reload 查询端口号80 是否开启： [ root@centos7 ~ ] # firewall-cmd --query-port=80/tcp 命令含义： –zone #作用域 –add-port=80/tcp #添加端口，格式为：端口/通讯协议 –permanent #永久生效，没有此参数重启后失效 关闭firewall： systemctl stop firewalld.service #停止firewall systemctl disable firewalld.service #禁止firewall开机启动 二、CentOS6防火墙开放端口： 在我们使用CentOS系统的时候，CentOS防火墙有时是需要改变设置的。CentOS防火墙默认是打开的，设置CentOS防火墙开放端口方法如下： 打开iptables的配置文件：vi /etc/sysconfig/iptables 修改CentOS防火墙时注意

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Java NIO中的 ServerSocketChannel 是一个可以监听新进来的TCP连接的通道, 就像标准IO中的ServerSocket一样。ServerSocketChannel类在 java.nio.channels包中。 这里有个例子： 查看源代码 打印 帮助 01 ServerSocketChannel serverSocketChannel = ServerSocketChannel.open(); 02 03 serverSocketChannel.socket().bind( new InetSocketAddress( 9999 )); 04 05 while ( true ){ 06 SocketChannel socketChannel = 07 serverSocketChannel.accept(); 08 09 //do something with socketChannel... 10 } 打开 ServerSocketChannel 通过调用 ServerSocketChannel.open() 方法来打开ServerSocketChannel.如： 查看源代码 打印 帮助 1 ServerSocketChannel serverSocketChannel =

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Java NIO中的 ServerSocketChannel 是一个可以监听新进来的TCP连接的通道, 就像标准IO中的ServerSocket一样。ServerSocketChannel类在 java.nio.channels包中。 这里有个例子： 01 ServerSocketChannel serverSocketChannel = ServerSocketChannel.open(); 02 03 serverSocketChannel.socket().bind(newInetSocketAddress(9999)); 04 05 while(true){ 06 SocketChannel socketChannel = 07 serverSocketChannel.accept(); 08 09 //do something with socketChannel... 10 } 打开 ServerSocketChannel 通过调用 ServerSocketChannel.open() 方法来打开ServerSocketChannel.如： 1 ServerSocketChannel serverSocketChannel = ServerSocketChannel.open(); 关闭

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 可读可写状态 1. 下列四个条件中的任何一个满足时，一个套接口准备好读： a. 该套接口接收缓冲区中的数据字节数 大等于 套接口接收缓冲区的低潮标记，对于 TCP 和 UDP 而言，其缺省值为 1 ； b. 该连接的读这一半关闭，对这样的套接口的读操作将不阻塞并返回 0 ； c. 该套接口是一个监听套接口且已完成的连接数不为 0 ；（就是 accept 成功返回 ) d. 其上有一个套接口错误等待处理，对这样的套接口的读操作将不阻塞并返回 -1 ； 2. 下列四个条件中的任何一个满足时，一个套接口准备好写： a. 该套接口发送缓冲区中的可用空间字节数 大等于 套接口发送缓冲区的低潮标记，对于 TCP 和 UDP 而言，其缺省值为 2048 ； b. 该连接的写这一半关闭，对这样的套接口的写操作将产生 SIGPIPE 信号； c. 该套接口早先使用非阻塞式 connect 以建立连接，并且连接已经异步建立，或者 connect 以失败告终； d. 其上有一个套接口错误等待处理，对这样的套接口的写操作将不阻塞并返回 -1 ； 3.select 与非阻塞 connect 一起使用的时候有以下两个注意点：（ 1 ）当连接成功建立时，描述字变为可写；（ 2 ）当连接建立遇到错误时，描述字变为既可读又可写；

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> linux 系统实现多个进程监听同一个端口 转自： http://blog.csdn.net/youjun9007228198/article/details/19946129 通过 fork 创建子进程的方式可以实现，其他情况下不行。 当连接到来时，子进程、父进程都可以 accept, 这就是著名的“惊群”问题(thundering herd problem)。 惊群现象 在该模型下（多个子进程同时共享监听套接字）即可实现服务器并发处理客户端的连接。这里要注意的是，计算机三次握手创建连接是不需要服务进程参数的，而服务进程仅仅要做的事调用accept将已建立的连接构建对应的连接套接字connfd（可参考 http://blog.csdn.net/ordeder/article/details/21551567）。多个服务进程同时阻塞在accept等待监听套接字已建立连接的信息，那么当内核在该监听套接字上建立一个连接，那么将同时唤起这些处于accept阻塞的服务进程，从而导致“惊群现象”的产生，唤起多余的进程间影响服务器的性能（仅有一个服务进程accept成功，其他进程被唤起后没抢到“连接”而再次进入休眠）。 一直疑惑一个应用app如何才能以多进程，多线程的方式运行。对于多线程可能很好理解

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 原文： http://www.cppblog.com/isware/archive/2011/07/20/151470.aspx “据说”惊群问题已经是一个很古老的问题了，并且在大多数系统中 已经得到有效解决 ，但对我来说，仍旧是一个比较新的概念，因此有必要记录一下。 什么是惊群 举一个很简单的例子，当你往一群鸽子中间扔一块食物，虽然最终只有一个鸽子抢到食物，但所有鸽子都会被惊动来争夺，没有抢到食物的鸽子只好回去继续睡觉，等待下一块食物到来。这样，每扔一块食物，都会惊动所有的鸽子，即为惊群。对于操作系统来说，多个进程/线程在等待同一资源是，也会产生类似的效果，其结果就是每当资源可用，所有的进程/线程都来竞争资源，造成的后果： 1）系统对用户进程/线程频繁的做无效的调度、上下文切换，系统系能大打折扣。 2）为了确保只有一个线程得到资源，用户必须对资源操作进行加锁保护，进一步加大了系统开销。 最常见的例子就是对于socket描述符的accept操作，当多个用户进程/线程监听在同一个端口上时，由于实际只可能accept一次，因此就会产生惊群现象，当然前面已经说过了，这个问题是一个古老的问题，新的操作系统内核已经解决了这一问题。 linux内核解决惊群问题的方法 对于一些已知的惊群问题，内核开发者增加了一个“互斥等待

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 问题产生的原因可以参考：https://www.youyong.top/article/1158f8b6782fb 我记录下自己的解决方案，因为被劫持的地址有个显著的特点，只有Accept: text/html类型的请求才会被劫持，因为之前我们系统虽然用了angurlar.js单却没有使用任何打包工具打包前端应用，导致Accept: text/html请求很多。鉴于此特性，也自然而然的想到把前端打包成一个单页应用，然后使用gulpfile打包前端，发现除了首页还有些Accept: text/html。实际打包是没有问题的，搞了半天最后才定位到，因为我们系统为了避免浏览器缓存影响，使用了一下方式的Url路由配置，导致请求相关页面时还是会直接请求页面：Accept: text/html。 templateUrl: function () { // 使用参数返回，可以加时时间戳避免每次发版导致的缓存问题 return "baseinfo.html?" + Math.random() } 然后统一改为，问题解决，这样就只有首页html会被劫持，对用户感知无影响。如果要彻底解决域名劫持问题，就是把网站升级为HTTPS。 templateUrl : "baseinfo.html" 此文仅仅为了记录

CentOS7默认的防火墙不是iptables,而是firewalle. 1、安装iptable iptable-service #先检查是否安装了iptables service iptables status #安装iptables yum install -y iptables #升级iptables（安装的最新版本则不需要） yum update iptables #安装iptables-services yum install iptables-services 2、禁用/停止自带的firewalld服务 #停止firewalld服务 systemctl stop firewalld #禁用firewalld服务 systemctl mask firewalld 3、设置现有规则 #查看iptables现有规则 iptables -L -n #先允许所有,不然有可能会杯具 iptables -P INPUT ACCEPT #清空所有默认规则 iptables -F #清空所有自定义规则 iptables -X #所有计数器归0 iptables -Z #允许来自于lo接口的数据包(本地访问) iptables -A INPUT -i lo -j ACCEPT #开放22端口 iptables -A INPUT -p tcp --dport 22 -j ACCEPT

REST全称是Representational State Transfer, 意思是表述(表征)性状态转移.REST是一组架构约束条件和原则. REST本身并没有创造新的技术, 组件和服务, 而隐藏在RESTful背后的理念就是使用WEB的现有特征和能力, 更好的使用现有Web标准中的一些准则和约束. 分别从资源的定义, 获取, 表述, 关联, 状态变迁等角度 　　资源与URI 　　统一资源接口 　　资源的表述 　　资源的链接 　　状态的转移 资源与URI 任何事物, 只要有被引用到的必要, 他就是一个资源, 资源可以是实体, 也可以只是一个抽象概念. 　　- 某用户的手机号 　　- 某用户的个人信息 　　- 最多用户订购的GPRS套餐 　　- 两个产品之间的依赖关系 　　- 某手机号的潜在价值 要让一个资源可以识别, 需要有一个唯一标识符, 在Web中这个唯一标识就是URI(Uniform Resource Identifier) URI既可以看成资源的地址, 也可以看成是资源的名称. 如果某些信息没有使用URI来表示, 那他就是一个资源, 只能算是一些信息而已. URI的设计应该遵循可寻址性原则, 具有自描述性, 需要在形式上给人直觉上的关联. 增加_或-分隔符分割一些单词, 让URI看起来更人性化 使用/来表示资源的层级关系 使用?用来过滤 , 或 ;

​ 在进行Coding时，常常遇到这样一种情况：设计的ADT，将来可能要扩展某些操作，但根据OCP原则，不应当修改已经实现的代码，所以需要提前留下扩展手段。设计模式中的Visitor模式就是契合这样一种设计理念的方法。 先看它的UML模型： 模型看起来有些复杂，不妨先明确几个概念： Visitor模式的实质 1、封装一些数据结构的各元素操作，降低操作间的耦合性。 2、将数据结构和数据操作解耦，使得易于扩展。 Visitor模式角色分工 1、Visitor: 抽象访问者， 在重载的visit方法中声明可以访问的对象 2、Concrete Visitor: 实现访问者对一个具体元素的操作 3、Element： 抽象元素， 提供重载的accpet方法（意义在于赋予访问权限，提高安全性） 4、Concrete Element： 实现accept方法 5、Object structure: 容纳多个Element Attention: Visitor模式的基本流程是Element是ADT，但不希望在其中实现一些操作（因为与本身关联度低），所以留了一个后门(accept方法），可以让特定的类获得它本身，从而进行相应的操作。特定的类同时需要有相应的进入后门的办法（visit方法），才能实现。 一个例子： 统计学生中男女生各自的数量 abstract class Student { ...