什么时候用StreamReader.ReadBlock()？我想知道Read(char[],int,int)无法返回请求的所有字符的情况，而ReadBlock()按预期返回所有字符（例如当StreamReader使用FileStream对象的实例时）。实际上，当使用StreamReader时，它很可能只发生在可能延迟一段时间的流上——比如人们在这里提到的网络流。但是，对于一般的TextReader，您可以期望它随时发生（包括可能在.NET的未来版本中-目前它不会-它不会发生在FileStream支持的StreamReader上）记录，所以不能保证不会发生将来）。特别是，在许多情况下，如果可以通过简单地清空当前缓冲区来部分完成调用，则实现者不返回请求的数量会更容易（通过更简单、更可靠且可能更高效的代码），或者在执行只能返回较少字符数的操作之前，使用请求的数量作为传递给后备源（流或其他TextReader）的数量。现在，回答有关“何时使用StreamReader.ReadBlock()？”的实际问题。（或更一般地说，何时使用TextReader.ReadBlock()）。应牢记以下几点：除非已读取整个源，否则Read()和ReadBlock()都保证返回至少一个字符。如果有未决的事情，它也不会返回0。在Read()执行时调用ReadBlock()是一种浪费，因为它会不必要地循环。但另一方面，也不是浪费。但在第三方面，Read()返回的字符少于请求的字符的情况通常是另一个线程参与获取将填充缓冲区以供下一次调用的内容，或者尚不存在的内容（例如用户输入或另一台机器上的未决操作）——在处理部分结果时找到更好的整体并发性，然后在完成后再次调用Read()。所以。如果您可以对部分结果做一些有用的事情，请调用Read()并处理您获得的结果。特别是如果您循环并处理每个Read()的结果，那么请执行此操作而不是使用ReadBlock()。一个值得注意的案例是，如果您正在构建自己的由另一个人支持的TextReader。除非该算法确实需要一定数量的字符才能工作，否则调用ReadBlock()没有任何意义-只需从对Read()的调用中返回尽可能多的内容，并在必要时让调用代码调用ReadBlock()。特别注意以下代码：charbuffer=char[4096];intlen=0;while((len=tr.ReadBlock(buffer,0,4096))!=0)DoSomething(buffer,0,len);可以被覆盖为：charbuffer=char[4096];for(intlen=tr.Read(buffer,0,4096);len!=0;len=tr.Read(buffer,0,4096))DoSomething(buffer,0,len);有时可能会以较小的大小调用DoSomething()，但如果另一个线程参与为下一次调用Read()提供数据，它也可以具有更好的并发性。然而，在大多数情况下，增益并不重要。如果确实需要一定数量的字符，则调用ReadBlock()。最重要的是，在Read()与ReadBlock()具有相同结果的情况下，ReadBlock()检查其是否已完成的开销非常小。不要试图猜测Read()在特定情况下是否安全；如果它需要ReadBlock()的保证，则使用ReadBlock()。这是网络流上的一个主要问题，特别是如果流数据非常大并且服务于Stream的服务器就像分块输出一样（即非常典型的HTTP），因为仅调用Read()即单个字符读取给出-1Once达到EOS，带有参数的Read(char[],int,int)调用达到所需的字符数或更少，如果达到EOS则返回读取的字符数，如果已经达到EOS则返回零而ReadBlock()等待从Stream中获取数据，因此您永远不会遇到这个问题。另一件需要注意的事情是，这两种形式都会读取最大数量的字符，如果没有那么多，则无法保证会返回很多。前段时间问过一个类似的问题——ReadingfromHttpResponseStreamfails-whenIreadfrom以上是C#学习教程在HTTP流中读取问题时：什么时候使用StreamReader.ReadBlock()？如果所有分享的内容对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
