理解线程池运行过程（ThreadPoolExecutor举例，打印线程池当前线程数、队列任务数、已完成数等信息）

 java  理解线程池运行过程（ThreadPoolExecutor举例，打印线程池当前线程数、队列任务数、已完成数等信息）已关闭评论
11月 292021
 

jdk提供了非常方便的方式来生成线程池， 如Executors.newxxxxxx的方式， 实现实际使用的都是以下ThreadPoolExecutor的方法：

/**
* Creates a new {@code ThreadPoolExecutor} with the given initial
* parameters.
*
* @param corePoolSize the number of threads to keep in the pool, even
* if they are idle, unless {@code allowCoreThreadTimeOut} is set
* @param maximumPoolSize the maximum number of threads to allow in the
* pool
* @param keepAliveTime when the number of threads is greater than
* the core, this is the maximum time that excess idle threads
* will wait for new tasks before terminating.
* @param unit the time unit for the {@code keepAliveTime} argument
* @param workQueue the queue to use for holding tasks before they are
* executed. This queue will hold only the {@code Runnable}
* tasks submitted by the {@code execute} method.
* @param threadFactory the factory to use when the executor
* creates a new thread
* @param handler the handler to use when execution is blocked
* because the thread bounds and queue capacities are reached
* @throws IllegalArgumentException if one of the following holds:<br>
* {@code corePoolSize < 0}<br>
* {@code keepAliveTime < 0}<br>
* {@code maximumPoolSize <= 0}<br>
* {@code maximumPoolSize < corePoolSize}
* @throws NullPointerException if {@code workQueue}
* or {@code threadFactory} or {@code handler} is null
*/

public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue<Runnable> workQueue, ThreadFactory threadFactory, RejectedExecutionHandler handler)

线程池的管理是这样一个过程：

首先创建线程池， 然后根据任务的数量逐步将线程增大到corePoolSize数量， 如果此时任有任务增加， 则放置到workQueue中， 直到workQueue爆满为止， 然后继续增加线程池中的线程数量，增加处理能力，最终达到maximumPoolSize。 如果此时还是有任务增加进来会怎样呢 ？ 这就需要handler来处理了，或者丢弃新任务， 或者拒绝新任务，或者挤占已有任务等。在任务队列何线程池都饱和情况下，一旦有线程处于等待（任务处理完毕， 没有新任务增加）状态的时间超过keepAliveTime，则该线程终止， 也就是说池中的线程数量会足部降低， 直至为corePoolSize数量为止。 至于threadFactory，可以自己新增一个，设置线程的自定义名称， daemon状态，便于后续排查错误。

我们用一个测试程序来帮助理解线程池的运行过程：

public class ThreadPoolTest {

private static ExecutorService es = new ThreadPoolExecutor(50, 100, 0L, TimeUnit.MILLISECONDS,new LinkedBlockingQueue<Runnable>(100000));

public static void main(String[] args) throws Exception {
for (int i = 0; i < 100000; i++) {
es.execute(() -> {
System.out.print(1);
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
});

}

ThreadPoolExecutor tpe = ((ThreadPoolExecutor) es);
while (true) {
System.out.println();
int queueSize = tpe.getQueue().size();
System.out.println(“当前排队任务数：” + queueSize);

int activeCount = tpe.getActiveCount();
System.out.println(“当前活动线程数：” + activeCount);

long completedTaskCount = tpe.getCompletedTaskCount();
System.out.println(“执行完成线程数：” + completedTaskCount);

long taskCount = tpe.getTaskCount();
System.out.println(“总线程数：” + taskCount);

Thread.sleep(3000);
}
}

}

 

程序每3秒打印一次线程池情况：

11111111111111111111111111111111111111111111111111
当前排队线程数：99950
当前活动线程数：50
执行完成线程数：0
总线程数：100000
1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
当前排队线程数：99849
当前活动线程数：50
执行完成线程数：127
总线程数：100000
111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
当前排队线程数：99700
当前活动线程数：50
执行完成线程数：250
总线程数：100000
111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
当前排队线程数：99550
当前活动线程数：50
执行完成线程数：400
总线程数：100000
111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
当前排队线程数：99400
当前活动线程数：50
执行完成线程数：550
总线程数：100000
111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
当前排队线程数：99250
当前活动线程数：50
执行完成线程数：700
总线程数：100000

。。。。。。

可以看到当前活动的线程数永远都是50， 为什么就没有突破？怎么没到100呢？ 大家可以思考下，相信看了上面的描述，很容易就能理解了，DONE！

 

PendingIntent的基本理解和使用

 android  PendingIntent的基本理解和使用已关闭评论
7月 032020
 

简书上看到的一篇PendingIntent的文章，收藏起来，链接：https://www.jianshu.com/p/a37f0ce2da2e

 

PendingIntent可以看作是对Intent的一个封装，但它不是立刻执行某个行为，而是满足某些条件或触发某些事件后才执行指定的行为(启动特定Service，Activity，BrcastReceive)。

我们可以把Pending Intent交给其他程序，其他程序按照PendingIntent进行操作。

在Alarm定时器与Notification通知中都使用了PendingIntent

1.获得PendingIntent类内部静态方法获得PendingIntent实例：

//获得一个用于启动特定Activity的PendingIntent

public static PendingIntent getActivity(Context context, int requestCode,Intent intent, int flags)

//获得一个用于启动特定Service的PendingIntent

public static PendingIntent getService(Context context, int requestCode,Intent intent, int flags)

//获得一个用于发送特定Broadcast的PendingIntent

public static PendingIntent getBroadcast(Context context, int requestCode,Intent intent, int flags)

参数说明：

context：上下文对象。

requstCode：请求码，发件人的私人请求代码（当前未使用）。

intent：请求意图。用于要指明要启动的类以及数据的传递；

flags：这是一个关键的标志位：

主要常量

FLAG_CANCEL_CURRENT:如果当前系统中已经存在一个相同的PendingIntent对象，那么就将先将已有的PendingIntent取消，然后重新生成一个PendingIntent对象。

FLAG_NO_CREATE:如果当前系统中不存在相同的PendingIntent对象，系统将不会创建该PendingIntent对象而是直接返回null。

FLAG_ONE_SHOT:该PendingIntent只作用一次。在该PendingIntent对象通过send()方法触发过后，PendingIntent将自动调用cancel()进行销毁，那么如果你再调用send()方法的话，系统将会返回一个SendIntentException。

FLAG_UPDATE_CURRENT:如果系统中有一个和你描述的PendingIntent对等的PendingInent，那么系统将使用该PendingIntent对象，但是会使用新的Intent来更新之前PendingIntent中的Intent对象数据，例如更新Intent中的Extras。

注意：两个PendingIntent对等是指它们的operation一样, 且其它们的Intent的action, data, categories, components和flags都一样。但是它们的Intent的Extra可以不一样。

 

swift闭包的@escaping和@noescape介绍与理解

 swift  swift闭包的@escaping和@noescape介绍与理解已关闭评论
3月 162020
 
swift闭包中关于@escaping与@noescape，下面的文章内容简洁易懂，转自链接：https://www.jianshu.com/p/905ba2a85455

OC的Block有一个坑，就是它的调用时机。

看下面两个方法，思考一下它们到底有什么区别。

- (void)methodAWithBlock:(void(^)())block {
    _block = block;
}
- (void)methodBWithBlock:(void(^)())block {
    block();
}
  • 第一个方法是将block作为实例变量存入当前的对象。常见的例子是异步的网络请求回调。
  • 第二个方法是立即调用这个传入来的block。常见的例子是数组的排序。

如果这是一个私有的类，@implementation看不到。那怎么判断这个block是拿来干什么的呢？答案是无法判断。

第一个方法里的Block是被当作实例变量接收了，例如该对象是A。对象A同时也被对象B持有，就成了这样B->A->block，这时block实现里引用了B，那么就变成了经典的B->A->block->B，引用循环。

可喜可贺的是如果我们不看内部实现，根本无法确切地判断出这个block是被对象A持有的。当然这是比较极端的例子，一般在声明方法时都会注明这个Block是作什么用的，只是在语言上无法防止这种不确定行为而已。

swift的闭包

有意思的是，swift在闭包上加强了静态检查。它有两个修饰词@escaping和@noescape。这个看代码就能说明。

    func addClosure(_ closure: @escaping ()->Void) {
        self.closure = closure
    }
    
    func doSomething(_ closure: ()->Void) {
        closure()
    }
  • 第一个方法加了@escaping，意味着“逃脱”，闭包的生命周期可以逃脱方法的作用域，在方法return后不会销毁，这意味着它的调用时机是不确定的，是异步的。一般用于异步网络请求。
  • 第二个没有修饰词，所以是默认的@noescape，这意味着该闭包不能超出方法的作用域，方法return后闭包就销毁了，所以它是安全的。

下面这种做法是会报错的，因为在方法doSomething返回后，闭包还存在于异步队列里等候调用。

    func doSomething(_ closure: ()->Void) {
        DispatchQueue(label: "queue").async {
            closure()
        }
    }

总结

看来swift作为编程语言在静态检查上比很多语言都强，但其实这么强的静态检查对养成好的编程习惯也是好事。

TLS,SSL,HTTPS理解

 python  TLS,SSL,HTTPS理解已关闭评论
9月 102016
 

需要了解的背景知识：

  • 术语 HTTPS,SSL,TLS
  • 长连接与短连接的关系
  • 了解 CA 证书
  • 基本流程

一.术语扫盲

1.什么是SSL？

SSL(Secure Sockets Layer, 安全套接字)，因为原先互联网上使用的 HTTP 协议是明文的，存在很多缺点——比如传输内容会被偷窥（嗅探）和篡改。发明 SSL 协议，就是为了解决这些问题。

2.那么什么是TLS呢？

到了1999年，SSL 因为应用广泛，已经成为互联网上的事实标准。IETF 就在那年把 SSL 标准化。标准化之后的名称改为 TLS（是“Transport Layer Security”的缩写），中文叫做“传输层安全协议”。

很多相关的文章都把这两者并列称呼（SSL/TLS），因为这两者可以视作同一个东西的不同阶段。

3.那么什么是HTTPS呢？

HTTPS = HTTP + SSL/TLS, 也就是 HTTP over SSL 或 HTTP over TLS.这是后面加S的由来

Untitled Image

相对于HTTP:

  • http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
  • http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

二.长连接VS短连接

HTTP对TCP的连接使用分为：

  • 短连接
  • 长连接(又称“持久连接”，或“Keep-Alive”或“Persistent Connection”)

如果是短连接的话，针对每个HTML资源，就会针对每一个外部资源，分别发起一个个 TCP 连接。相反，如果是“长连接”的方式，浏览器也会先发起一个 TCP 连接去抓取页面。但是抓取页面之后，该 TCP 连接并不会立即关闭，而是暂时先保持着（所谓的“Keep-Alive”）。然后浏览器分析 HTML 源码之后，发现有很多外部资源，就用刚才那个 TCP 连接去抓取此页面的外部资源。

注意：

  • 在 HTTP 1.0 版本，【默认】使用的是“短连接”（那时候是 Web 诞生初期，网页相对简单，“短连接”的问题不大）
  • 在 HTTP 1.1 中，【默认】采用的是“Keep-Alive”的方式。

三.HTTPS的设计

HTTPS的设计要兼容HTTP

  • HTTPS 还是要基于 TCP 来传输
  • 单独使用一个新的协议，把 HTTP 协议包裹起来（所谓的“HTTP over SSL”，实际上是在原有的 HTTP 数据外面加了一层 SSL 的封装。HTTP 协议原有的 GET、POST 之类的机制，基本上原封不动）

关于HTTPS的性能，为了确保性能，SSL 的设计者至少要考虑如下几点：

  • 如何选择加密算法（“对称”or“非对称”）？
  • 如何兼顾 HTTP 采用的“短连接”TCP 方式？

四.简单运行过程

SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。

问题：

  • 如何保证公钥不被篡改？:解决方法：将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。
  • 公钥加密计算量太大，如何减少耗用的时间？解决方法：每一次对话（session），客户端和服务器端都生成一个”对话密钥”（session key），用它来加密信息。由于”对话密钥”是对称加密，所以运算速度非常快，而服务器公钥只用于加密”对话密钥”本身，这样就减少了加密运算的消耗时间。

因此，SSL/TLS协议的基本过程是这样的：

  • 客户端向服务器端索要并验证公钥。
  • 双方协商生成”对话密钥”。
  • 双方采用”对话密钥”进行加密通信。

如下图解:

Untitled Image

五.详解运行过程

如下图示：

Untitled Image

注意的是，”握手阶段”的所有通信都是明文的

1.客户端发出请求（ClientHello）

C向S提供信息如下：

  • 支持的协议版本，比如TLS 1.0版。
  • 一个客户端生成的随机数，稍后用于生成”对话密钥”。
  • 支持的加密方法，比如RSA公钥加密。
  • 支持的压缩方法。

2.服务器回应（SeverHello）

服务器收到客户端请求后，向客户端发出回应，这叫做SeverHello。服务器的回应包含以下内容。

  • 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
  • 一个服务器生成的随机数，稍后用于生成”对话密钥”。
  • 确认使用的加密方法，比如RSA公钥加密。
  • 服务器证书。

除了上面这些信息，如果服务器需要确认客户端的身份，就会再包含一项请求，要求客户端提供”客户端证书”。

3.客户端回应

客户端收到服务器回应以后，首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。

如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后，向服务器发送下面三项信息。

  • 一个随机数。该随机数用服务器公钥加密，防止被窃听。
  • 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
  • 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。

现在总共有3个随机数，第三个又称”pre-master key”，有了它以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自 生成 本次会话 所用的 同一把 “会话密钥”。

4.服务器的最后回应

服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的”会话密钥”。然后，向客户端最后发送下面信息。

  • 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
  • 服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。

至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用”会话密钥”加密内容。

Untitled Image

六.Https的劣势

不完整总结如下：

  • 对数据进行加解密决定了它比http慢
  • https协议需要到CA申请证书。

转自：http://beginman.cn/python/2016/05/27/ssh-with-python/?utm_source=tuicool&utm_medium=referral

SO_LINGER理解

 tcp/ip  SO_LINGER理解已关闭评论
12月 192014
 

整理网上资料理解SO_LINGER

Normal TCP termination

The normal TCP termination sequence looks like this (simplified):

We have two peers: A and B

  1. A calls close()

    • A sends FIN to B
    • A goes into FIN_WAIT_1 state
  2. B receives FIN

    • B sends ACK to A
    • B goes into CLOSE_WAIT state
  3. A receives ACK

    • A goes into FIN_WAIT_2 state
  4. B calls close()

    • B sends FIN to A
    • B goes into LAST_ACK state
  5. A receives FIN

    • A sends ACK to B
    • A goes into TIME_WAIT state
  6. B receives ACK

    • B goes to CLOSED state – i.e. is removed from the socket tables

TIME_WAIT

So the peer that initiates the termination – i.e. calls close() first – will end up in the TIME_WAIT state.

To understand why the TIME_WAIT state is our friend, please read section 2.7 in “UNIX Network Programming” third edition by Stevens et al (page 43).

However, it can be a problem with lots of sockets in TIME_WAIT state on a server as it could eventually prevent new connections from being accepted.

To work around this problem, I have seen many suggesting to set the SO_LINGER socket option with timeout 0 before calling close(). However, this is a bad solution as it causes the TCP connection to be terminated with an error.

Instead, design your application protocol so the connection termination is always initiated from the client side. If the client always knows when it has read all remaining data it can initiate the termination sequence. As an example, a browser knows from the Content-Length HTTP header when it has read all data and can initiate the close. (I know that in HTTP 1.1 it will keep it open for a while for a possible reuse, and then close it.)

有下列三种情况：

1、设置 l_onoff为0，则该选项关闭，l_linger的值被忽略，等于内核缺省情况，close调用会立即返回给调用者，如果可能将会传输任何未发送的数据；

 

2、设置 l_onoff为非0，l_linger为0，则套接口关闭时TCP夭折连接，TCP将丢弃保留在套接口发送缓冲区中的任何数据并发送一个RST给对方，而不是通常的四分组终止序列，这避免了TIME_WAIT状态；

 

3、设置 l_onoff 为非0，l_linger为非0，当套接口关闭时内核将拖延一段时间（由l_linger决定）。如果套接口缓冲区中仍残留数据，进程将处于睡眠状态，直 到（a）所有数据发送完且被对方确认，之后进行正常的终止序列（描述字访问计数为0）或（b）延迟时间到。此种情况下，应用程序检查close的返回值是非常重要的，如果在数据发送完并被确认前时间到，close将返回EWOULDBLOCK错误且套接口发送缓冲区中的任何数据都丢失。close的成功返回仅告诉我们发送的数据（和FIN）已由对方TCP确认，它并不能告诉我们对方应用进程是否已读了数据。如果套接口设为非阻塞的，它将不等待close完成。