在 Azure 上传文件的时候遇到了一个下面的异常： java.io.IOException: mark/reset not supported at java.base/java.io.InputStream.reset(InputStream.java:655) at com.azure.storage.common.Utility.lambda$convertStreamToByteBuffer$4(Utility.java:236) at reactor.core.publisher.FluxDefer.subscribe(FluxDefer.java:46) at reactor.core.publisher.Mono.subscribe(Mono.java:4213) 问题解决 当给定的流不支持 mark 和 reset 就会报这个错误。 我们用的代码是： blobClient.upload(inputStream , inputStream.available()); InputStream 是不支持 mark 和 reset 的。 BufferedInputStream继承于FilterInputStream，提供缓冲输入流功能。 缓冲输入流相对于普通输入流的优势是，它提供了一个缓冲数组，每次调用read方法的时候，它首先尝试从缓冲区里读取数据，若读取失败（缓冲区无可读数据），则选择从物理数据源（例如你指定的文件）读取新数据（这里会尝试尽可能读取多的字节）放入到缓冲区中，最后再将缓冲区中的内容部分或全部返回给用户。 由于从缓冲区里读取数据远比直接从物理数据源（譬如文件）读取速度快。 Azure 使用上面的方法来尽量保障数据能够上传到存储中。 解决方案是用 BufferedInputStream 再把原来的流包装一层。 什么时候会出现这种错误呢，当你获得一个 InputStream 流，这个流是不允许读写头来回移动，也就不允许 mark/reset 机制。 所以上面的代码修改为： blobClient.upload(new BufferedInputStream(inputStream) , inputStream.available());     然后再重试，你就会看到文件上传上去了。 登录控制台查看上传的文件。     https://www.ossez.com/t/java-io-ioexception-mark-reset-not-supported/617/2

在文件上传到服务器的时候，我们希望能够获得文件的指纹以确定文件没有被篡改过。 常用的算法最开始使用的是 MD5，随后随着技术的发展，MD5 算法已经被确定是不安全的了。 目前可能使用更多的是 HSA3_256 哈希算法。 哈希算法通常有以下几个特点： 正像快速：原始数据可以快速计算出哈希值 逆向困难：通过哈希值基本不可能推导出原始数据 输入敏感：原始数据只要有一点变动，得到的哈希值差别很大 冲突避免：很难找到不同的原始数据得到相同的哈希值 哈希算法主要有MD4、MD5、SHA。 MD4 1990年 输出128位 （已经不安全） MD5 1991年 输出128位 （已经不安全） SHA-0 1993年 输出160位 （发布之后很快就被NSA撤回，是SHA-1的前身） SHA-1 1995年 输出160位 （已经不安全） SHA-2包括SHA-224、SHA-256、SHA-384，和 SHA-512，分别输出224、256、384、512位。 (目前安全) 在 Java 中，可以使用 Apache 提供的 Apache Commons Codec，非常容易的获得文件的哈希字符串指纹。 方法也非常简单，第一步就是需要将文件读取为 InputStream。 如果自己写的话，可能这一步有点代码。 你可以使用 Apache 提供的 FileUtils.openInputStream 就可以直接将文件读取为 InputStream 了。 考察下面的代码： InputStream is = FileUtils.openInputStream(new File(SCOConstants.PATH_DATA_EXCHANGE + "Estimated vs Original Manual (JIRA) 10-23-20.csv")); MD5 哈希     在文件读取后，你只需要使用 Apache Commons Codec 提供的 DigestUtils 方法就可以了。 /** * Test to get file's MD5 Hash * * @throws Exception */ @Test public void fileMD5Test() throws Exception { String md5 = StringUtils.EMPTY; try { InputStream is = FileUtils.openInputStream(new File(SCOConstants.PATH_DATA_EXCHANGE + "Estimated vs Original Manual (JIRA) 10-23-20.csv")); md5 = DigestUtils.md5Hex(is); } catch (Exception e) { e.printStackTrace(); } logger.debug("MD5 for File: {}", md5); } 上面的代码就可以直接获得 InputStream 的 MD5 哈希。 程序的输出为： 09:32:31.522 [main] DEBUG c.i.s.c.t.utilities.CodecUtilsTest - MD5 for File: 1ec6473fc1bd50a982767f555734af64 SHA3 256 与 MD5 哈希算法是一致的。       你需要首先也将文件读取为 InputStream ，然后使用 Apache 提供的 DigestUtils.sha3_256Hex(is); 就可以了。 考察下面的代码： /** * Test to get file's SHA3_256Hex Hash * * @throws Exception */ @Test public void fileSHA3_256HexTest() throws Exception { String sha3Hex256 = StringUtils.EMPTY; try { InputStream is = FileUtils.openInputStream(new File(SCOConstants.PATH_DATA_EXCHANGE + "Estimated vs Original Manual (JIRA) 10-23-20.csv")); sha3Hex256 = DigestUtils.sha3_256Hex(is); } catch (Exception e) { e.printStackTrace(); } logger.debug("SHA3_256Hex for File: {}", sha3Hex256); } 运行程序的输出为： 09:35:48.093 [main] DEBUG c.i.s.c.t.utilities.CodecUtilsTest - SHA3_256Hex for File: https://www.ossez.com/t/java/615

很多公司都在做这方面的转型。 尤其是在公司达到一定运营规模后，PHP 的问题会让公司花费更多的时间去部署排查问题。当时公司选择 PHP 的主要原因，就是因为开发简单，框架也还不错，部署也比较快。持续集成的问题可能没有太多的问题。 如果一开始要上 Java 的话，很多时候需要面临从框架，数据库，ORM，CI，DevOps 各个不同方面的技术协调和沟通，对不是财大气粗的公司来说，这个负担还是比较重的。毕竟人力成本还在那里摆着。 相对以前来说，现在 Java 世界也保持比较开放的态度，有 Spring 全家桶，基本上能够帮你解决很多快速部署的问题，采取微服务可以前台和后台分离，采取混合云架构，可以将一些网络和存储压力转移。 其实不管选何种语言都差不多，可能你们公司在使用 PHP 的时候已经达到了 PHP 的性能瓶颈和极限了，转型 Java 再正常不过了。也有用 .NET 的，很多公司不会考虑，主要是版权问题和微软绑定的问题。     另外，如果你搜索在互联网世界中有多少个网站使用 Java 有多少网站使用 PHP 的，这个其实是没有任何意义的。因为一个 WordPress 就能碾压很多网站了。 PHP 的优势在于快速部署，没有多少人愿意花费几天时间去安装数据库，部署应用，调试 Log ，并且界面还不好调整。 使用 PHP 能够飞速部署一些小应用，对个人，初创公司，想利用一些已有的框架的时候就非常方便了。 https://www.ossez.com/t/php-java/592

在 Hibernate 或者 ORM 映射中，我们可能会存在 1 对多的情况。 在这个时候，如果你使用 Jackson 将对象序列化的时候，就会出现双向引用导致的无限递归（infinite recursion）的情况。 @JsonManagedReference 和 @JsonBackReference 注解就是为了避免这个双向引用的情况。 @JsonBackReference 和 @JsonManagedReference：这两个标注通常配对使用，通常用在父子关系中。 假设我们有 2 个对象。 一个对象是 QIndex 和 QTitle 一个 QIndex 可能对应有多个 QTitle。 那么在 JPA 中的对应关系的 QIndex 应该定义为： @OneToMany(mappedBy = "qIndex", cascade = CascadeType.ALL, orphanRemoval = true) @OrderBy("questionNumber ASC") @JsonManagedReference private List<QTitle> qTitleList = new ArrayList<>(); 在 JPA 的 QTitle 中应该定义为： @ManyToOne() @JsonBackReference private QIndex qIndex; 在序列化的时候，@JsonManagedReference 注解的属性则会被序列化，@JsonBackReference 的注解将会被忽略。 @JsonManagedReference 注解，通常说明这个字段是一个双向引用的字段，这个字段在这个双向引用中的角色为 “父”，与这个字段对应的引用需要注解为 @JsonBackReference。 @JsonBackReference 注解，通常说明这个字段是关联的一个双向引用字段，这个字段在这个双向引用的角色是 “孩子”。这个字段的值只能是对象（Bean），不能是 集合（Collection），图（Map），数组（Array）和枚举类型（enumeration）。 总结 @JsonManagedReference 和 @JsonBackReference 总是成对出现的 @JsonManagedReference 定义在父级角色 @JsonBackReference 定义在孩子级角色 @JsonBackReference 不能使用任何集合和数组等多的数据结构     有了上面的解释，应该比较容易的理解为了避免双向引用导致无限递归而出现的问题的。 https://www.ossez.com/t/jackson-jsonmanagedreference-jsonbackreference/574  

不需要。直接修改环境变量就可以了。 根据使用的操作系统不同，不同的操作系统可能有所不同。 Windows 的话 PATH 看一下 指向的 JDK 是哪个路径。 如果你要CMD 查看的话，你需要关闭 CMD 窗口，然后重新打开。

你可用使用 Guava 的 Longs 进行转换。 例如，你希望将 917525L 转换为二进制数组，可用使用下面的语句。 上面的方法可用直接使用。 同时你需要 import from Guava import com.google.common.primitives.Longs; 上面就可以转换为二进制数组了。 https://www.ossez.com/t/java-long-bytearray/213

lib 管理，Maven 项目使用 POM 管理你的约束，你也可以将你的 Lib 发布到仓库中供其他人使用。 使用版本号，Package 进行管理，极大的方便了 Java 项目。

不是十分明白你说的 Java 逻辑思维很差。 不管学什么语言，基本上都应该差不多吧，语言应该是对实际场景和业务的描述和实现，但是不同语言的实现方式不一样罢了。 Java 在语言当中，个人还是属于比较中规中矩的语言，可能是 OO 让你比较困惑，而且 Java 有个特点是约束大于方法的情况。你可能会遇到各种概念非常多，XML 配置，属性配置文件，对象，接口，实现，类，抽象类，映射，反射… 在 OO Java 的概念可能非常多，也可能让你非常困惑，各种网络上的文章，介绍很少能帮助初学者通过一个比较直观的方式去理解。这个可能是你遇到所谓的逻辑思维很差的问题。 其实学 Java 你是需要了解并且熟悉一些概念的，这些概念你不熟悉，越到后面越一头雾水，根本搞不清在干什么。相对来说 Java 在 OO 里面是纯 OO 的，当你明白这些概念后，一切都会迎刃而解。 个人的建议是，你需要找一个真正有需求的项目，吃透它。其实当你吃透一个项目后，后面很多都会好办了，缺什么补什么。 比如说，针对现在的的 Covid-19，你希望获得什么实现？展示当前的数据情况并且进行分析。那么你首先要知道你数据来源在哪里，数据来源有了，那么 API 是怎么实现的，API 实现了你怎么存储到你的数据库或者 NOSQL 中，数据存下来了你怎么在你的网站或者页面中展示，你要用什么框架，你要用什么应用服务器，你应用服务器要不要方向代理，你的应用服务器要不要集群。 当你把这一套关系都搞清楚了，一切都容易了。

JDK 的使用都是历史遗留问题。   很多应用一旦使用了 JDK 很少会变化，尤其是现在新的 JDK 变动太多，新 JDK 编译的东西老 JDK 用不了。   除非到了非升级不可的程度，比如说以前是用 J2EE 开发的，现在可能需要采用微服务，但是一些已有的 common 是老的 JDK 编译的，这个时候可以重新使用新的 JDK 进行编译然后升级 JDK。 除此之外如果不是业务必须的，升级 JDK 的成本太高，意义不大。

JDK 的版本有变化，但是没有想象中的那么大了。   你现在用 9 ，公司用 8 ，对你实际使用问题不大。为什么很多公司还在一直用 8 的原因是历史遗留问题。JDK 升级不是那么简单的，你可能需要所有用的依赖都要升级。   很多历史的 Jar 是在老版本上编译的，你升级你项目 JDK 可能这些 Jar 用不了。   你知道还有不少公司用 JDK 1.4 的吗？   对个人学习来说，用 8 和 9 都差不多，但是尽量不要用 9 才有的特性，这样你的代码也能够在 8 上面跑。   JDK 9 现在已知有点问题，如果是新项目要跳过 8 用的话，你可以直接开始用 11。