Chrome 88正式版发布下载
|
GIL 后来，多线程编程技术流行了起来，进程里不止我一个线程了，又来了几个新的伙伴。 本以为我们能和平共处，没想到这一来就麻烦了，我们几个各干各的，经常把内存空间搞出问题，也找不到背锅的人。 终于有一天，我实在忍受不了了，召集大家商讨个解决办法。 “小伙伴们，咱们不能再这样各搞各的了，咱们是一个Team，要彼此协作，一个线程可以走的很快，但一群线程在一起才能走的更远呐!” “老大，你有什么想法你就直说吧”，另一个线程说到。 “要不，咱们加个锁吧!简单快捷，每个线程要执行代码，都得来申请这个锁，申请到了才能执行，否则就得等着”，我说到。 “那什么时候释放呢?” “要不弄个计数器，每个线程数到100就释放，这样保证别人有机会来执行?” “那怎么计数呢?每执行一个字节码就计数一次吗?” “可以，不过也不用那么死板，有些指令比较简单的，很快可以完成，就可以不用计数了” “好是好，但要是还没数够100，却在执行I/O操作阻塞了，还把锁霸占的话，那不是资源浪费吗?”
小伙伴们七嘴八舌的讨论着。 年月日的处理上似乎可以接受没有问题了。从结果中可以发现，Calendar年份的传值不用再减去1900了，这和Date是不一样的，不知道这种行为不一致会不会让有些人抓狂。
另外，还有个重点是Calendar依旧是可变的，所以存在不安全因素，参与计算改变值时请使用其副本变量。 总的来说，Calendar在Date的基础上做了改善，但仅限于修修补补，并未从根本上解决问题。最重要的是Calendar的API使用起来真的很不方便，而且该类在语义上也完全不符合日期/时间的含义，使用起来更显尴尬。 总之，无论是Date，还是Calendar，还是格式化DateFormat都用着太方便，且存在各式各样的安全隐患、线程安全问题等等，这是API没有设计好的地方。 并不孤单 日期时间API属于基础API，在各个语言中都是必备的。然而不仅仅是Java面临着API设计很烂的处境，有些其它流行语言一样如此，涌现出1个(1堆)三方库比乙方库设计更好的情况，比如：
所以说，Java它并不孤单(自我安慰一把) 自我救赎：JSR 310 因为原生的Date日期时间体系存在“七宗罪”，催生了第三方Java日期时间库的诞生，如大名鼎鼎的Joda-Time的流行甚至一度成为标配。 对于Java来说，如此重要的API模块岂能被第三方库给占据，开发者本就想简单的处理个日期时间还得导入第三方库，使用也太不方便了吧。当时的Java如日中天，因此就开启了“收编”Joda-Time之旅。
2013年9月份，具有划时代意义的Java 8大版本正式发布，该版本带来了非常多的新特性，其中最引入瞩目之一便是全新的日期时间API：JSR 310。 （编辑：潍坊站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
