rr_ssl_weak_server_ephemeral_dh_key

chrome

有些https加密的网站在IE中能够访问,但是Firefox/Chrome中会出现rr_ssl_weak_server_ephemeral_dh_key这样的错误码。究其原因,还是新版本的浏览器放弃了对SSL1/2/3/TLSv1(TLSv1.1?不清楚)的支持,要求必须强制使用TLSv1.2(或者更高?)版本的安全协议。另附JDK中支持的协议说明:

Here are the available protocols on each platform.

Platform Available Protocols
JDK 5, 6 SSLv2Hello(1), SSLv3, TLSv1
JDK 7, 8, 9 (Early Access) SSLv2Hello(2), SSLv3, TLSv1, TLSv1.1, TLSv1.2

 

利用keytool转换p12为jks

keytool位于<JAVA_HOME>/bin

1、创建一个jks密钥库文件

2、导入p12证书

Java ImageIO处理图像的封装

文章转载自这里,非常感谢作者!!!

继续阅读Java ImageIO处理图像的封装

Java获取本机IP地址

网上比较流行的一种方法:

 

不过,在我的Linux上不好用啊,仅仅是可以获得 127.0.0.1 这个环回地址,实在是不怎么样。貌似在windows下好用(没测试过)。
最后,看了这位仁兄的帖子,用的是这个:

 

Java的命运

本文是Common Lisp专家Peter Seibel对Google公司首席Java架构师Joshua Bloch的访谈,谈到他所遇到的最糟糕的Bug以及Java的命运。

最糟糕的Bug

Seibel:我们聊聊调试吧。你遇到的最糟糕的Bug是什么?
Bloch:提起Bug我立马就想到了一个,这个Bug很严重,而且很搞笑。那是90年代初,我在匹兹堡的Transarc公司工作时。我在很紧的工期下提交了一个事务共享内存的实现。我在限期内完成了设计和实现,甚至还在过程中做出了几个可重用的组件。但是这么匆忙地写了很多新代码,我还是挺担心的。

为了测试这些代码,我写了一个叫做“乱撞”的很长的程序出来。它运行了大量的事务,每个事务又包含了嵌套的事务,嵌套到可以嵌套的最大深度。每个嵌套事务都可能会加锁,以递增的顺序读取共享数组里面的几个元素,对每个元素都加入点东西,保持数组中所有元素的和为0,还是不变量。这些事务要么提交,要么取消,如90%的提交,10%的取消,其他比例也可以。多个线程同步运行于这些事务之上,长时间地访问数组。因为我测试的是一个共享内存机制,所以我同时运行多个有多个线程的“乱撞”程序,每个有自己的进程。

在一般的并发级别下,“乱撞”轻松过关。但是当我真正调高并发级别时,我发现“乱撞”偶尔,仅仅是偶尔,无法通过一致性检查。我不知道这是怎么搞的。这只能是我的错,因为新代码都是我一个人写的。

我花了大约一个星期,痛苦地为每个组件写了彻底的单元测试,所有的单元测试都通过了。然后我为每个内部数据结构写了详细的一致性检查,这样我就可以在每次变化后调用这些一致性检查,直到测试失败为止。最后,我终于发现一个底层的一致性检查失败了,这个问题无法重现,但是某种程度上可以帮助我分析问题出在哪里。最后,我得出了确实的结论——我的锁根本不工作。两个事务锁定、读写同一个值的时候,产生了并发的读—修改—写回操作,而后一次写入毁掉了第一次的写入。

我编写了自己的锁管理器,所以我怀疑是它出了问题。但是锁管理器轻松地通过了测试。最后,我觉得问题不在锁管理器,而是它依赖的互斥体的实现!那时候操作系统还不支持多线程,我们需要写自己的多线程包。原来负责互斥体代码的工程师,不小心把我们的Solaris的线程实现中的lock和try-lock的汇编代码的标签弄混了。所以,每次你以为你在调用lock的时候,其实调用的是try-lock,反之亦然。也就是说当真的有争用发生的时候——在当年其实是很罕见的——第二个线程直接就进入了第一个线程的临界区,因为第一个线程也没有锁住。搞笑的是,这也就是说,整个公司几个星期都在运行没有互斥体的程序,而且谁都不知道。
继续阅读Java的命运