Assuming you‘re looking for a quick tactical fix, what you need to do is make sure the cell image is initialized and also that the cell‘s row is still visible, e.g.:

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath{

    myCell *cell = [tableView dequeueReusableCellWithIdentifier:@"cell"];
    if (cell == nil) {
        cell = [[myCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:@"cell"];
    }

    cell.poster.image = nil; // or cell.poster.image = [UIImage imageNamed:@"placeholder.png"];

    dispatch_async(kBgQueue, ^{
        NSData *imgData = [NSData dataWithContentsOfURL:[NSURL URLWithString:[NSString stringWithFormat:@"http://myurl.com/%@.jpg",[[myJson objectAtIndex:indexPath.row] objectForKey:@"movieId"]]]];
        if (imgData) {
            UIImage *image = [UIImage imageWithData:imgData];
            if (image) {
                dispatch_async(dispatch_get_main_queue(), ^{
                    myCell *updateCell = (id)[tableView cellForRowAtIndexPath:indexPath];
                    if (updateCell)
                        updateCell.poster.image = image;
                });
            }
        }
    });
    return cell;
}

The above code addresses two problems stemming from the fact that the cell is reused:

1. You‘re not initializing the cell image before you initiating the background request (meaning that the last image for the dequeued cell will still be there). Reset that. That‘s the more significant problem here.

2. A more subtle issue is that on a really slow network, your asynchronous request might not finish before the cell scrolls off the screen. You can use the UITableView method cellForRowAtIndexPath: (not to be confused with the similarly named UITableViewDataSource method tableView:cellForRowAtIndexPath:) to see if the cell for that row is still visible. This method will return nil if the cell is not visible.

   The issue is that the cell has scrolled off by the time your async method has completed, and, worse, the cell has been reused for another row of the table. By checking to see if the row is still visible, you‘ll ensure that you don‘t accidentally update the image with the image for a row that has since scrolled off the screen.

   This approach will also work with the sendAsynchronousRequest rendition, too.

An even better fix, though, is to use a UIImageView category, such as is provided with SDWebImage or AFNetworking, which will, handle this more efficiently canceling the request in progress if the cell‘s image view has been reused for another cell. On a very slow network, if you scroll quickly through the first, for example, 50 images for the first 50 rows of the tableview, your implementation (which is one I used to advocate until I better appreciated this subtlety) will continue trying to load images that have since scrolled off the screen, making it very slow to respond to that 51st image that you need for the currently visible cell.

These UIImageView categories also solve an additional problem with your code: cacheing. You really don‘t want to re-retrieve the image from the network when you scroll back and look at previous rows. Judicious use of NSCache (which those categories use) will dramatically improve performance and reduce redundant network requests.

If you want, you can write your own imageview category, but it‘s a lot of work, and SDWebImage or AFNetworking has done this already for you.